From sthorger at redhat.com  Fri Mar  1 02:10:51 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 1 Mar 2019 08:10:51 +0100
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
In-Reply-To: <TY2PR01MB454004225E04FC9C4DF5450BC9760@TY2PR01MB4540.jpnprd01.prod.outlook.com>
References: <CAJgngAdCOusGh0Mf1yHO4TA9j54C9gG48WMi3Uba0+GvFDMs7Q@mail.gmail.com>
	<TY2PR01MB4540BFE30A76A20F0CF2C8ECC9740@TY2PR01MB4540.jpnprd01.prod.outlook.com>
	<CAJgngAcJak=OEHW2YTyNQhUBc5S1FBJz+qNRFCFm=e8NXNbvQA@mail.gmail.com>
	<TY2PR01MB454004225E04FC9C4DF5450BC9760@TY2PR01MB4540.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAeLg5PZvRpSFJjoKXS+AmAjRmtN2z-XZvik5fZ9NehbYA@mail.gmail.com>

Great, thanks

On Fri, 1 Mar 2019 at 05:34, ???? / NAKAMURA?YUUICHI <
yuichi.nakamura.fe at hitachi.com> wrote:

>
> > Do you have an idea on roughly when you can have a prototype ready?
> It is difficult to estimate for now, but hopefully within this month
> (March).
> We will tell you as soon as it is available.
>
> Regards,
> Yuichi Nakamura
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Thursday, February 28, 2019 6:53 PM
> To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an
> WebAuthn4j extension
>
> That's great, thanks.
>
> Do you have an idea on roughly when you can have a prototype ready?
>
> On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> My team has begun to help webauthn4j project,
> and is going to develop prototype of authenticator for keycloak.
> We'd like to take this.
>
> Regards,
> Yuichi Nakamura
> Hitachi, Ltd.
>
> -----Original Message-----
> From: mailto:keycloak-dev-bounces at lists.jboss.org <mailto:
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Thursday, February 28, 2019 12:26 AM
> To: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
> Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j
> extension
>
> A while back I created an experimental extension to Keycloak for FIDO U2F.
> It would be great if someone could adapt this to WebAuthn by leveraging
> webauthn4j library [1].
>
> Any takers? It shouldn't be hard ;)
>
> [1]
> https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
> _______________________________________________
> keycloak-dev mailing list
> mailto:keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>

From dhardiker at adaptavist.com  Fri Mar  1 18:12:47 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Fri, 1 Mar 2019 23:12:47 +0000
Subject: [keycloak-dev] Improving support for LDAP backed Keycloak
In-Reply-To: <8F7BE3E5-1836-4793-A85F-066ADB5BF062@adaptavist.com>
References: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>
	<08405d13-3621-5ac2-3021-606295bc71c6@redhat.com>
	<8F7BE3E5-1836-4793-A85F-066ADB5BF062@adaptavist.com>
Message-ID: <2C92E2EE-CE11-409B-A8E2-EDA597F4EEBC@adaptavist.com>

Hi All,

So I?ve continued and have Keycloak extended to support KEYCLOAK-5571. Notably, I can setup LDAP attribute mappers for the enabled (boolean), emailVerified (boolean), and requiredActions (Set<String>) model fields and they work as expected. I did not need to store TOTP, it seems to just work but if I?m missing a scenario where it doesn?t, the same approach should work.

Required Actions caused me a bit of effort. It does not have a setter on the proxy like the others, instead is has addRequiredAction/removeRequiredAction mutator methods. This means I?ve had to detect the requiredAction model field in a couple of areas to short-circuit so that errors don?t crop up in the logs. It?s still functional without those short-circuits (as Required Actions are handled later in the processes) but the logs can get noisy and confusingly point to a problem that?s not there. Personally I think it?s cleaner to short-circuit. [If I?m not being clear, I can try to explain again differently.]

Because of my unfamiliarity with Github, I?ve ended up opening a Draft Pull Request. I wanted to do it within my own fork, but ended up doing it live. I?ve left it so you can see where I?m up to. A quick review of my approach would be very welcome as I?ve never committed to Keycloak before and would appreciate a nod that I?m going in the right direction with all this.

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

I have no automated tests yet, it?s just been a manual development cycle as it was slow enough getting up to speed with the code base, let alone the LDAP side of the test harness! I?ll move onto that next and hopefully with that and completing the rest of the committer guidance, it?ll be soon accepted!


?
Dan Hardiker | Adaptavist
dhardiker at adaptavist.com
 
Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc

Adaptavist, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
Registered in England and Wales #5456785.

> On 22 Feb 2019, at 12:54, Dan Hardiker <dhardiker at adaptavist.com> wrote:
> 
> Hi All,
> 
> Thanks for the pointers. I was able to get Keycloak imported properly into IDEA (a bit of user error, needed a lot more patience). I?ve worked out how to get Keycloak running with a remote debugger, which has been a great help, but I?ve not managed to get Keycloak running from within IDEA itself. Is it standard to run it through mvn during development?
> 
> I?ve got a basic implementation working against a custom attribute I?ve set. It?s not tested, I?m first looking for validation on the approach taken. Can someone please have a look at https://github.com/dhardiker/keycloak/commit/e26ff98c2d4c55b98b743522d195226b94b4c8aa - all comments welcome, so I can make sure I?m on the right path. Tests will come before a PR is submitted.
> 
> Other questions:
> 
> 1. Should I address the other KEYCLOAK-5571 issues too in the same branch of work?
> 2. I?ve found that boolean fields sometimes map inversely to common LDAP attributes one might choose to back Keycloak with (e.g. UserModel.enabled <> LDAPUser.loginDisabled). Would it be ok to add another setting to the UserAttributeLDAPStorageMapper which would be ?Invert boolean values? - so an UserModel.enabled == true maps to setting LDAPUser.loginDisabled = false? If so, any tips on where the areas to extend that in, beyond the Mapper itself (I?m thinking at least a theme or two?).
> 
> Thanks for the continued support, I?m starting to feel a little more comfortable with the Keycloak codebase.
> 
> 
> ?
> Dan Hardiker | Adaptavist
> dhardiker at adaptavist.com
>  
> Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc
> 
> Adaptavist, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
> Registered in England and Wales #5456785.
> 
>> On 20 Feb 2019, at 13:03, Marek Posolda <mposolda at redhat.com> wrote:
>> 
>> On 18/02/2019 18:39, Dan Hardiker wrote:
>>> Hi All,
>>> 
>>> Sorry for such a long first post. Here we go!
>>> 
>>> 
>>> TL;DR:
>>> I want to look at 
>>> https://issues.jboss.org/browse/KEYCLOAK-5571 as it is impacting us. I?m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here?s a few of my currently burning questions:
>> Cool!
>>> 1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can?t find the business logic)
>> The implementation is "auto-generated" proxy class, which just invokes the particular admin REST endpoint - for example org.keycloak.admin.client.resource.UserResource.update is invoked the server-side REST endpoint org.keycloak.services.resources.admin.UserResource.updateUser
>>> 2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)
>> 
>> UserAttributeLDAPStorageMapper is the class where you can look at. As you can see in the "proxy" method, the proxied model implements setFirstName, setLastNAme, setEmail .
>> It seems that few more things need to be added (EG. setEnabled, setEmailVerified)
>> 
>> The automated test may need to be added somewhere in LDAPProvidersIntegrationTest IMO.
>> 
>>> 3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn?t seem to cut it.
>> Importing the root POM into IDEA works fine for me.
>>> 4. If I provide a patch for this, is this something that might be considered for pulling into master?
>> Yes. There needs to be few simple rules met when you want something to be considered into master. We're working on improving guidelines for contributors. See details in this PR: https://github.com/keycloak/keycloak/pull/5886/files . You just already started the discussion on keycloak-dev mailing list, which is nice 1st step. Good luck with moving forward on your contribution!
>> 
>> Marek
>> 
>>> I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I?m happy to start here and treat the others as atomic suggested changes. They may include:
>>> 
>>> * Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see ? i.e. the next available UID).
>>> * Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.
>>> 
>>> If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.
>>> 
>>> Thanks for your time, I would love to get involved ? I just need a bit of help.
>>> 
>>> 
>>> THE SAGA:
>>> Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I?ve been fighting in circles all weekend and I have to admit that I?m not entirely sure I?m approaching the problem correctly. Please bear with me as I?m not entirely sure how to articulate things at this point, but I know I need help!
>>> 
>>> Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.
>>> 
>>> As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I?ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I?m having. Amongst other things, I?m a Java developer, so I?m comfortable with working in code and submitting patches. Assuming that the answer isn?t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?
>>> 
>>> What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn?t make it through to LDAP.
>>> 
>>> I noticed that there was a PUT to 
>>> http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME
>>>  and as part of the JSON payload was ?enabled: false?. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn?t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)? in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn?t find the glue which connects them together. I?m guessing there might be some WildFly or other magic going on which I?m not aware of?
>>> 
>>> Seeing the ?enabled: false? lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute ?enabled? to an ?enabled? LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I?ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too? - however there is no ?Always read value from LDAP? option! However, after enabling Import Users in the LDAP user federation settings, ?Always read value from LDAP? becomes available. It?s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it?s not erroring about not properly persisting the enabled state to LDAP...
>>> 
>>> If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is ?enabled?:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it?s sending enabled: FALSE - this doesn?t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.
>>> 
>>> Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = ?ENABLED? field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:
>>> 
>>> * Assumes everything is managed by federated storage except for username.  getId() returns a default value
>>> * of "f:" + providerId + ":" + getUsername().  UserModel properties like enabled, firstName, lastName, email, etc. are all
>>> * stored as attributes in federated storage.
>>> 
>>> I?m not sure how the case difference between ?enabled? in the UserModel properties and ?ENABLED? as listed in the class field is connected - but there must be a mapping somewhere, as ?firstName? is similarly ?FIRST_NAME? and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED?) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?
>>> 
>>> I?ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I?m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I?ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I?ve also yet to comb through the H2 DB to see if there?s cause there.
>>> 
>>> Any assistance on this would be most welcome.
>>> 
>>> 
>>> ON ANOTHER NOTE:
>>> I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here?s some excerpts from the output:
>>> [INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]
>>> 
>>> [ERROR] Errors:
>>> [ERROR]   OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 ? Processing
>>> [ERROR]   OIDCKeycloakServerBrokerWithConsentTest.before:84 ? Processing java.lang.NoSuc...
>>> [ERROR]   BrokenUserStorageTest.testBootWithBadProviderId:118 ? Processing java.lang.NoS...
>>> [ERROR]   JaxrsBasicAuthTest.testBasic:120 ? NoSuchMethod org.apache.commons.io.output.D...
>>> [ERROR]   JaxrsFilterTest.testBasic:129 ? NoSuchMethod org.apache.commons.io.output.Defe...
>>> [ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32
>>> 
>>> I guess this shouldn?t happen on a fresh check out & a following of the instruction.
>>> 
>>> 
>>> If you made it this far - bravo!
>>> 
>>> Thanks again,
>>> 
>>> 
>>> ?
>>> Dan Hardiker | Adaptavist
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> 
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> 
> 



From mposolda at redhat.com  Mon Mar  4 06:06:23 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 4 Mar 2019 12:06:23 +0100
Subject: [keycloak-dev] Removing JaxrsBearerTokenFilter
In-Reply-To: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
References: <78951f7b-57b4-c64b-a1f4-9b7fdcae56af@redhat.com>
Message-ID: <639585fc-5a4d-1a8b-ddaa-b3ad0bc1c74b@redhat.com>

For now, we just remove the automated tests and we deprecated jaxrs 
filter. This change will be from Keycloak 5.0.0

We may remove the filter itself in some later Keycloak 6.X, so if you 
want to keep using it, I suggest to fork it into your repository and we 
can then reference it from the extensions page [1] as a an extension 
maintained by community. Please let us know in that case, so there are 
not more people working on a maintenance on this.

[1] https://www.keycloak.org/extensions.html

Thanks!
Marek


On 20/02/2019 14:35, Marek Posolda wrote:
> I wonder if we can remove JaxrsBearerTokenFilter?
>
> Jut to add some context, the JaxrsBearerTokenFilter is the "adapter", 
> which we have in the codebase and which allows to "secure" the JaxRS 
> Application by adding the JaxrsFilter, which implements our OIDC 
> adapter. Bill added this thing in the early days of Keycloak. I 
> enhanced it a bit few years ago as someone wanted to secure the JaxRS 
> application on Fuse. But this was before we had the proper Fuse adapter.
>
> This thing was never documented and we never had any 
> examples/quickstarts for it. We have just few automated tests (in the 
> old testsuite). IMO it is very obsolete now as you can probably always 
> secure your application through some other oficially supported way 
> (HTTP Servlet filter or any of our other built-in adapters).
>
> Does anyone have any reason why we shouldn't remove this?
>
> If not, I wonder if we can remove it directly without "deprecation 
> period"? Considering that this was never documented or announced, it 
> probably can't be treated as a Keycloak feature, but rather an 
> "implementation detail" or "prototype" and hence removing it directly 
> may be fine? In this case, we won't need to migrate the tests from the 
> old testsuite (which is my main motivation for writing this email :)
>
> Marek
>


From dhardiker at adaptavist.com  Mon Mar  4 14:53:23 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Mon, 4 Mar 2019 19:53:23 +0000
Subject: [keycloak-dev] Improving support for LDAP backed Keycloak
In-Reply-To: <2C92E2EE-CE11-409B-A8E2-EDA597F4EEBC@adaptavist.com>
References: <9695FE33-85A2-48BC-B440-D50452D070DF@adaptavist.com>
	<08405d13-3621-5ac2-3021-606295bc71c6@redhat.com>
	<8F7BE3E5-1836-4793-A85F-066ADB5BF062@adaptavist.com>
	<2C92E2EE-CE11-409B-A8E2-EDA597F4EEBC@adaptavist.com>
Message-ID: <B873316D-0F5F-4887-98A6-9C4ADCDEC18B@adaptavist.com>

Hi All,

Continuing my journey, I found that I was unable to create users through Keycloak, as they had to have the objectClass: posixAccount, which has uidNumber, gidNumber and homeDirectory all as mandatory fields. During creation, first the UsersResource.createUser method would add an empty user to LDAP and then update it with the information passed in. The UserAttributeLDAPStorageMapper.onRegisterUserToLDAP method would use ? ? as the default for mappers marked as mandatory in LDAP, however, ? ? doesn?t work for numeric fields.

The simplest thing would be for Keycloak to store ?0" instead of ? ? for mandatory attributes with a numeric syntax, but Keycloak doesn?t have knowledge of the attribute syntax (at least, not from within this method as far as I can tell).

The next minimal change I could determine was to add a ?LDAP Default Value? configuration option to the UserAttributeLDAPStorageMapperFactory.getConfigProps method, and use that instead of LDAPConstants.EMPTY_ATTRIBUTE_VALUE (defaulting to this if the config property is missing, for backward compatibility).

I?ve added this to my current work on KEYCLOAK-5571 as it?s intrinsically linked to my work on improving support for LDAP backed Keycloak. Please let me know if this is inappropriate and I?ll raise a separate JIRA (which might already exist) and split the patch out. You can find the commit with this change here: https://github.com/dhardiker/keycloak/commit/67b9b029784074b6ec580c786898ae4ef9e23497

With this, I think this completes our immediate show stopping issues with using Keycloak in front of our OpenLDAP installation. As ever, I welcome code review before I find the time to expand the test coverage and comply with the other PR requirements!

Thanks,


?
Dan Hardiker | Adaptavist
dhardiker at adaptavist.com
 
Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc

Adaptavist, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
Registered in England and Wales #5456785.

> On 1 Mar 2019, at 23:12, Dan Hardiker <dhardiker at adaptavist.com> wrote:
> 
> Hi All,
> 
> So I?ve continued and have Keycloak extended to support KEYCLOAK-5571. Notably, I can setup LDAP attribute mappers for the enabled (boolean), emailVerified (boolean), and requiredActions (Set<String>) model fields and they work as expected. I did not need to store TOTP, it seems to just work but if I?m missing a scenario where it doesn?t, the same approach should work.
> 
> Required Actions caused me a bit of effort. It does not have a setter on the proxy like the others, instead is has addRequiredAction/removeRequiredAction mutator methods. This means I?ve had to detect the requiredAction model field in a couple of areas to short-circuit so that errors don?t crop up in the logs. It?s still functional without those short-circuits (as Required Actions are handled later in the processes) but the logs can get noisy and confusingly point to a problem that?s not there. Personally I think it?s cleaner to short-circuit. [If I?m not being clear, I can try to explain again differently.]
> 
> Because of my unfamiliarity with Github, I?ve ended up opening a Draft Pull Request. I wanted to do it within my own fork, but ended up doing it live. I?ve left it so you can see where I?m up to. A quick review of my approach would be very welcome as I?ve never committed to Keycloak before and would appreciate a nod that I?m going in the right direction with all this.
> 
> https://github.com/keycloak/keycloak/pull/5908
> 
> I have no automated tests yet, it?s just been a manual development cycle as it was slow enough getting up to speed with the code base, let alone the LDAP side of the test harness! I?ll move onto that next and hopefully with that and completing the rest of the committer guidance, it?ll be soon accepted!
> 
> 
> ?
> Dan Hardiker | Adaptavist
> dhardiker at adaptavist.com
> 
> Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc
> 
> Adaptavist, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
> Registered in England and Wales #5456785.
> 
>> On 22 Feb 2019, at 12:54, Dan Hardiker <dhardiker at adaptavist.com> wrote:
>> 
>> Hi All,
>> 
>> Thanks for the pointers. I was able to get Keycloak imported properly into IDEA (a bit of user error, needed a lot more patience). I?ve worked out how to get Keycloak running with a remote debugger, which has been a great help, but I?ve not managed to get Keycloak running from within IDEA itself. Is it standard to run it through mvn during development?
>> 
>> I?ve got a basic implementation working against a custom attribute I?ve set. It?s not tested, I?m first looking for validation on the approach taken. Can someone please have a look at https://github.com/dhardiker/keycloak/commit/e26ff98c2d4c55b98b743522d195226b94b4c8aa - all comments welcome, so I can make sure I?m on the right path. Tests will come before a PR is submitted.
>> 
>> Other questions:
>> 
>> 1. Should I address the other KEYCLOAK-5571 issues too in the same branch of work?
>> 2. I?ve found that boolean fields sometimes map inversely to common LDAP attributes one might choose to back Keycloak with (e.g. UserModel.enabled <> LDAPUser.loginDisabled). Would it be ok to add another setting to the UserAttributeLDAPStorageMapper which would be ?Invert boolean values? - so an UserModel.enabled == true maps to setting LDAPUser.loginDisabled = false? If so, any tips on where the areas to extend that in, beyond the Mapper itself (I?m thinking at least a theme or two?).
>> 
>> Thanks for the continued support, I?m starting to feel a little more comfortable with the Keycloak codebase.
>> 
>> 
>> ?
>> Dan Hardiker | Adaptavist
>> dhardiker at adaptavist.com
>> 
>> Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc
>> 
>> Adaptavist, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
>> Registered in England and Wales #5456785.
>> 
>>> On 20 Feb 2019, at 13:03, Marek Posolda <mposolda at redhat.com> wrote:
>>> 
>>> On 18/02/2019 18:39, Dan Hardiker wrote:
>>>> Hi All,
>>>> 
>>>> Sorry for such a long first post. Here we go!
>>>> 
>>>> 
>>>> TL;DR:
>>>> I want to look at 
>>>> https://issues.jboss.org/browse/KEYCLOAK-5571 as it is impacting us. I?m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here?s a few of my currently burning questions:
>>> Cool!
>>>> 1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can?t find the business logic)
>>> The implementation is "auto-generated" proxy class, which just invokes the particular admin REST endpoint - for example org.keycloak.admin.client.resource.UserResource.update is invoked the server-side REST endpoint org.keycloak.services.resources.admin.UserResource.updateUser
>>>> 2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)
>>> 
>>> UserAttributeLDAPStorageMapper is the class where you can look at. As you can see in the "proxy" method, the proxied model implements setFirstName, setLastNAme, setEmail .
>>> It seems that few more things need to be added (EG. setEnabled, setEmailVerified)
>>> 
>>> The automated test may need to be added somewhere in LDAPProvidersIntegrationTest IMO.
>>> 
>>>> 3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn?t seem to cut it.
>>> Importing the root POM into IDEA works fine for me.
>>>> 4. If I provide a patch for this, is this something that might be considered for pulling into master?
>>> Yes. There needs to be few simple rules met when you want something to be considered into master. We're working on improving guidelines for contributors. See details in this PR: https://github.com/keycloak/keycloak/pull/5886/files . You just already started the discussion on keycloak-dev mailing list, which is nice 1st step. Good luck with moving forward on your contribution!
>>> 
>>> Marek
>>> 
>>>> I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I?m happy to start here and treat the others as atomic suggested changes. They may include:
>>>> 
>>>> * Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see ? i.e. the next available UID).
>>>> * Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.
>>>> 
>>>> If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.
>>>> 
>>>> Thanks for your time, I would love to get involved ? I just need a bit of help.
>>>> 
>>>> 
>>>> THE SAGA:
>>>> Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I?ve been fighting in circles all weekend and I have to admit that I?m not entirely sure I?m approaching the problem correctly. Please bear with me as I?m not entirely sure how to articulate things at this point, but I know I need help!
>>>> 
>>>> Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.
>>>> 
>>>> As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I?ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I?m having. Amongst other things, I?m a Java developer, so I?m comfortable with working in code and submitting patches. Assuming that the answer isn?t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?
>>>> 
>>>> What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn?t make it through to LDAP.
>>>> 
>>>> I noticed that there was a PUT to 
>>>> http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME
>>>> and as part of the JSON payload was ?enabled: false?. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn?t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)? in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn?t find the glue which connects them together. I?m guessing there might be some WildFly or other magic going on which I?m not aware of?
>>>> 
>>>> Seeing the ?enabled: false? lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute ?enabled? to an ?enabled? LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I?ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too? - however there is no ?Always read value from LDAP? option! However, after enabling Import Users in the LDAP user federation settings, ?Always read value from LDAP? becomes available. It?s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it?s not erroring about not properly persisting the enabled state to LDAP...
>>>> 
>>>> If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is ?enabled?:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it?s sending enabled: FALSE - this doesn?t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.
>>>> 
>>>> Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = ?ENABLED? field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:
>>>> 
>>>> * Assumes everything is managed by federated storage except for username.  getId() returns a default value
>>>> * of "f:" + providerId + ":" + getUsername().  UserModel properties like enabled, firstName, lastName, email, etc. are all
>>>> * stored as attributes in federated storage.
>>>> 
>>>> I?m not sure how the case difference between ?enabled? in the UserModel properties and ?ENABLED? as listed in the class field is connected - but there must be a mapping somewhere, as ?firstName? is similarly ?FIRST_NAME? and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED?) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?
>>>> 
>>>> I?ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I?m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I?ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I?ve also yet to comb through the H2 DB to see if there?s cause there.
>>>> 
>>>> Any assistance on this would be most welcome.
>>>> 
>>>> 
>>>> ON ANOTHER NOTE:
>>>> I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here?s some excerpts from the output:
>>>> [INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]
>>>> 
>>>> [ERROR] Errors:
>>>> [ERROR]   OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 ? Processing
>>>> [ERROR]   OIDCKeycloakServerBrokerWithConsentTest.before:84 ? Processing java.lang.NoSuc...
>>>> [ERROR]   BrokenUserStorageTest.testBootWithBadProviderId:118 ? Processing java.lang.NoS...
>>>> [ERROR]   JaxrsBasicAuthTest.testBasic:120 ? NoSuchMethod org.apache.commons.io.output.D...
>>>> [ERROR]   JaxrsFilterTest.testBasic:129 ? NoSuchMethod org.apache.commons.io.output.Defe...
>>>> [ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32
>>>> 
>>>> I guess this shouldn?t happen on a fresh check out & a following of the instruction.
>>>> 
>>>> 
>>>> If you made it this far - bravo!
>>>> 
>>>> Thanks again,
>>>> 
>>>> 
>>>> ?
>>>> Dan Hardiker | Adaptavist
>>>> 
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> 
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> 
>>> 
>> 
> 



From liqiang at fit2cloud.com  Tue Mar  5 06:32:24 2019
From: liqiang at fit2cloud.com (=?UTF-8?B?5byg56uL5by6?=)
Date: Tue, 5 Mar 2019 19:32:24 +0800
Subject: [keycloak-dev] https://github.com/keycloak/keycloak/pull/5906
Message-ID: <CAOHSYr5C5ejW954yz4iTHJZ_W6c2ni=49czbZxJXRubhnYZUVw@mail.gmail.com>

Hi,

Can anyone check out this PR?
https://github.com/keycloak/keycloak/pull/5906

Thanks.

???

?????, FIT2CLOUD

http://fit2cloud.com | Mobile +86-18701062478 <%2B86-17710309880>

???????????7????????A?715?


????????????????????? ??? ? ??? ? ???

From sthorger at redhat.com  Tue Mar  5 12:45:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Mar 2019 18:45:35 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
Message-ID: <CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>

Was hoping for some more feedback from the list on this one.

Especially around not having any authentication of the clients wanting to
initiate an action. I feel reasonable comfortable about not securing it and
requiring actions to prompt the user before doing anything, but welcome
others opinion on it.

On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:

> Since there is no "silent" application initiated action (always
> prompts user) possible and actions are predefined at keycloak I see no
> need for the client/application restriction mechanism.
>
> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > Keycloak currently has required actions that are used to prompt the user
> to
> > perform an action associated with their account after authenticating, but
> > prior to being redirected to the application.
> >
> > Examples include: configure OTP, update profile, validate email, etc.
> >
> > One issue here is these actions have to be manually registered with the
> > users account, but can not be initiated by applications themselves. As an
> > example it may not be required by all users to verify their email, but
> only
> > when they use specific applications.
> >
> > Keycloak also needs to initiate actions from the account management
> > console. Examples: updating email address should require verifying the
> > email, configuring OTP, etc.
> >
> > With that in mind we are proposing to introduce Application Initiated
> > Actions. An Application Initiated Action behind the scenes is just a
> > Required Action, but it is initiated by an application and depending on
> the
> > action may be optional for the user to complete (where the user can
> select
> > cancel which would return the user back to the application).
> >
> > No Application Initiated Actions should perform any updates to the users
> > account without prompting the user first. For example an application
> > initiated action that is used to link an existing account to a social
> > provider should ask the user first if they want to link to the provider.
> >
> > To make it easy for applications to integrate these I would like to
> > leverage the standard OAuth flows that applications use to authenticate
> > users. So to initiate verify-email action the application would redirect
> to
> > the authentication endpoint and add kc_action=<action alias> query
> > parameter.
> >
> > One open question I have right now is. Assuming all Application Initiated
> > Actions always prompt the user first do we need to add some mechanism in
> > place to restrict what clients/applications are permitted to initiate an
> > action? Requiring that would make it harder to use for applications.
> >
> > One thing I would also like to add is the ability for an Application
> > Initiated Action to require the user to re-authenticate prior to
> performing
> > the action. For example update password should require the user to enter
> > the current password, while verify email should not (as it simply sends
> an
> > email with a link to continue).
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Wed Mar  6 03:59:58 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 6 Mar 2019 09:59:58 +0100
Subject: [keycloak-dev] Translations missing for roles: query-users,
 query-clients, uma_protection, query-groups
Message-ID: <CAK-7U1hhNyRgWWbuu2=Mo4==OY406LCFL16BbJ48EFbXkG+=Dg@mail.gmail.com>

Hello,

I just noticed that some role translations are missing in the realm-admin
console.
If you go to Clients -> realm-management -> Roles you see some empty
descriptions.

In keycloak/themes/src/main/resources/theme/base/login/messages/messages_en.properties
https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/login/messages/messages_en.properties#L129

Just created: https://issues.jboss.org/browse/KEYCLOAK-9747

Cheers,
Thomas

From kundateeri.babji at gmail.com  Wed Mar  6 06:07:53 2019
From: kundateeri.babji at gmail.com (Babji Kundateeri)
Date: Wed, 6 Mar 2019 16:37:53 +0530
Subject: [keycloak-dev] Multi Tenant Support
Message-ID: <CA+YA1yJ2ABStQ=87Ymn=+6cLuOzf5y5rG09PVL-M22JkCbpzWg@mail.gmail.com>

Hi Team,

We have a application with multi tenant system which uses simple form based
authentication.

Now we are planning to adopt keycloak to our system to have our own idp to
get more flexibility of authentication.

Our plan is to create a Realm for each customer is it fine to go with ?

Can you suggest me a way forward / best approach to solve this problem?

-- 
Kind Regards,
Babji Kundateeri.

From Sebastian.Loesch at governikus.de  Wed Mar  6 06:17:24 2019
From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=)
Date: Wed, 6 Mar 2019 11:17:24 +0000
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
In-Reply-To: <CAJgngAfc9PcC37Y4n7onxhzr-FMCjhCrCG=4Zrs=jbjy5RbT5A@mail.gmail.com>
References: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
	<CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>
	<d3ca8e635b09445d9f8a5a231863a602@BOSKGEXC01.boskg.local>
	<CAJgngAfc9PcC37Y4n7onxhzr-FMCjhCrCG=4Zrs=jbjy5RbT5A@mail.gmail.com>
Message-ID: <1dd9101d7a584ca3a8a1a9111f08ae87@BOSKGEXC02.boskg.local>

Hello devs,



I developed an alternative approach: https://github.com/keycloak/keycloak/pull/5907

It is backward compatible but open to new types of AdminEvent.



Is this suitable for you?



Best regards,

Sebastian





Von: Stian Thorgersen <sthorger at redhat.com>
Gesendet: Mittwoch, 20. Februar 2019 15:31
An: L?sch, Sebastian <Sebastian.Loesch at governikus.de>
Cc: keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] Allow AdminEvents for custom resource types







On Wed, 20 Feb 2019 at 12:40, L?sch, Sebastian <Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>> wrote:

   >We can't accept the PR as is due to it breaking backwards compatibility of the API.

   Ah, I overlooked the EventListenerProvider interface. That?s the point where AdminEvent becomes public API, right?



   It's not really public, but loads of people still use it. So yes, that's the main place.





   Our use-case is as follows: we need to support user substitutions. User Jane goes for vacation and nominates John as her substitute in a defined time period. John has all of Janes Roles and is able to perform her tasks.

   We implement this substitution as a keycloak extension. All substitutions must be tracked. We want to implement this using the AdminEvents.



   Do you have any other suggestions how we can accomplish tracking?



   Contribute it directly to Keycloak? Depends obviously on how much changes is needed, how it's designed, if can be properly documented and tested, etc.



   Alternatively, you could find an alternative approach that is backwards compatible. Perhaps ResourceType enum can be extended or somehow allowed to add custom types to it?





   Best regards,

   Sebastian



   Von: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
   Gesendet: Mittwoch, 20. Februar 2019 11:42
   An: L?sch, Sebastian <Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>>
   Cc: keycloak-dev <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
   Betreff: Re: [keycloak-dev] Allow AdminEvents for custom resource types



   We can't accept the PR as is due to it breaking backwards compatibility of the API.



   Can you elaborate on your use-case? I'm far from convinced we should support this level of customisation.



   On Wed, 20 Feb 2019, 05:32 L?sch, Sebastian, <Sebastian.Loesch at governikus.de<mailto:Sebastian.Loesch at governikus.de>> wrote:

      Hello devs,

      we implemented a custom resource type as an extension to keycloak.
      For traceability reasons we would like to track actions for this custom resource type via AdminEvents.
      Unfortunately the resource type is represented by the enum ResourceType. Therefore no AdminEvents for custom non standard resource types can be created.
      It would be nice if it is possible to specify the resource type as string value also.

      This is only a small change, because the resource type is only provided via enum but handled as string value internally.
      I provided a pull request for that enhancement: https://github.com/keycloak/keycloak/pull/5882

      May anybody have a look on that review?

      Best regards,
      Sebastian



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


From psilva at redhat.com  Wed Mar  6 08:23:34 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Mar 2019 10:23:34 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
Message-ID: <CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>

IMO, we should have some level of authorization for clients initiating an
action. This could be as simple as leveraging authz in order to define
white/black lists of clients. Similar to what a KC extension does in
regards to authentication.

On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com> wrote:

> Was hoping for some more feedback from the list on this one.
>
> Especially around not having any authentication of the clients wanting to
> initiate an action. I feel reasonable comfortable about not securing it and
> requiring actions to prompt the user before doing anything, but welcome
> others opinion on it.
>
> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>
> > Since there is no "silent" application initiated action (always
> > prompts user) possible and actions are predefined at keycloak I see no
> > need for the client/application restriction mechanism.
> >
> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> > >
> > > Keycloak currently has required actions that are used to prompt the
> user
> > to
> > > perform an action associated with their account after authenticating,
> but
> > > prior to being redirected to the application.
> > >
> > > Examples include: configure OTP, update profile, validate email, etc.
> > >
> > > One issue here is these actions have to be manually registered with the
> > > users account, but can not be initiated by applications themselves. As
> an
> > > example it may not be required by all users to verify their email, but
> > only
> > > when they use specific applications.
> > >
> > > Keycloak also needs to initiate actions from the account management
> > > console. Examples: updating email address should require verifying the
> > > email, configuring OTP, etc.
> > >
> > > With that in mind we are proposing to introduce Application Initiated
> > > Actions. An Application Initiated Action behind the scenes is just a
> > > Required Action, but it is initiated by an application and depending on
> > the
> > > action may be optional for the user to complete (where the user can
> > select
> > > cancel which would return the user back to the application).
> > >
> > > No Application Initiated Actions should perform any updates to the
> users
> > > account without prompting the user first. For example an application
> > > initiated action that is used to link an existing account to a social
> > > provider should ask the user first if they want to link to the
> provider.
> > >
> > > To make it easy for applications to integrate these I would like to
> > > leverage the standard OAuth flows that applications use to authenticate
> > > users. So to initiate verify-email action the application would
> redirect
> > to
> > > the authentication endpoint and add kc_action=<action alias> query
> > > parameter.
> > >
> > > One open question I have right now is. Assuming all Application
> Initiated
> > > Actions always prompt the user first do we need to add some mechanism
> in
> > > place to restrict what clients/applications are permitted to initiate
> an
> > > action? Requiring that would make it harder to use for applications.
> > >
> > > One thing I would also like to add is the ability for an Application
> > > Initiated Action to require the user to re-authenticate prior to
> > performing
> > > the action. For example update password should require the user to
> enter
> > > the current password, while verify email should not (as it simply sends
> > an
> > > email with a link to continue).
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Mar  6 08:25:45 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Mar 2019 14:25:45 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
Message-ID: <CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>

The issue is more around how to authenticate clients and also the fact that
clients wanting to initiate actions may be public clients. We also don't
want to invent a new protocol for this, but rather just rely on the OIDC
flows.

So with those constraints how would you authenticate the client?

On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com> wrote:

> IMO, we should have some level of authorization for clients initiating an
> action. This could be as simple as leveraging authz in order to define
> white/black lists of clients. Similar to what a KC extension does in
> regards to authentication.
>
> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Was hoping for some more feedback from the list on this one.
>>
>> Especially around not having any authentication of the clients wanting to
>> initiate an action. I feel reasonable comfortable about not securing it
>> and
>> requiring actions to prompt the user before doing anything, but welcome
>> others opinion on it.
>>
>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>>
>> > Since there is no "silent" application initiated action (always
>> > prompts user) possible and actions are predefined at keycloak I see no
>> > need for the client/application restriction mechanism.
>> >
>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com>
>> > wrote:
>> > >
>> > > Keycloak currently has required actions that are used to prompt the
>> user
>> > to
>> > > perform an action associated with their account after authenticating,
>> but
>> > > prior to being redirected to the application.
>> > >
>> > > Examples include: configure OTP, update profile, validate email, etc.
>> > >
>> > > One issue here is these actions have to be manually registered with
>> the
>> > > users account, but can not be initiated by applications themselves.
>> As an
>> > > example it may not be required by all users to verify their email, but
>> > only
>> > > when they use specific applications.
>> > >
>> > > Keycloak also needs to initiate actions from the account management
>> > > console. Examples: updating email address should require verifying the
>> > > email, configuring OTP, etc.
>> > >
>> > > With that in mind we are proposing to introduce Application Initiated
>> > > Actions. An Application Initiated Action behind the scenes is just a
>> > > Required Action, but it is initiated by an application and depending
>> on
>> > the
>> > > action may be optional for the user to complete (where the user can
>> > select
>> > > cancel which would return the user back to the application).
>> > >
>> > > No Application Initiated Actions should perform any updates to the
>> users
>> > > account without prompting the user first. For example an application
>> > > initiated action that is used to link an existing account to a social
>> > > provider should ask the user first if they want to link to the
>> provider.
>> > >
>> > > To make it easy for applications to integrate these I would like to
>> > > leverage the standard OAuth flows that applications use to
>> authenticate
>> > > users. So to initiate verify-email action the application would
>> redirect
>> > to
>> > > the authentication endpoint and add kc_action=<action alias> query
>> > > parameter.
>> > >
>> > > One open question I have right now is. Assuming all Application
>> Initiated
>> > > Actions always prompt the user first do we need to add some mechanism
>> in
>> > > place to restrict what clients/applications are permitted to initiate
>> an
>> > > action? Requiring that would make it harder to use for applications.
>> > >
>> > > One thing I would also like to add is the ability for an Application
>> > > Initiated Action to require the user to re-authenticate prior to
>> > performing
>> > > the action. For example update password should require the user to
>> enter
>> > > the current password, while verify email should not (as it simply
>> sends
>> > an
>> > > email with a link to continue).
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From psilva at redhat.com  Wed Mar  6 08:30:59 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Mar 2019 10:30:59 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
Message-ID: <CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>

One way is to follow authorization code constraints like checking the
client_id and redirect_uri (assuming the user will be redirected back after
the action completes). But still, we could also add some level
authorization.

On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> The issue is more around how to authenticate clients and also the fact
> that clients wanting to initiate actions may be public clients. We also
> don't want to invent a new protocol for this, but rather just rely on the
> OIDC flows.
>
> So with those constraints how would you authenticate the client?
>
> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> IMO, we should have some level of authorization for clients initiating an
>> action. This could be as simple as leveraging authz in order to define
>> white/black lists of clients. Similar to what a KC extension does in
>> regards to authentication.
>>
>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Was hoping for some more feedback from the list on this one.
>>>
>>> Especially around not having any authentication of the clients wanting to
>>> initiate an action. I feel reasonable comfortable about not securing it
>>> and
>>> requiring actions to prompt the user before doing anything, but welcome
>>> others opinion on it.
>>>
>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>>>
>>> > Since there is no "silent" application initiated action (always
>>> > prompts user) possible and actions are predefined at keycloak I see no
>>> > need for the client/application restriction mechanism.
>>> >
>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com>
>>> > wrote:
>>> > >
>>> > > Keycloak currently has required actions that are used to prompt the
>>> user
>>> > to
>>> > > perform an action associated with their account after
>>> authenticating, but
>>> > > prior to being redirected to the application.
>>> > >
>>> > > Examples include: configure OTP, update profile, validate email, etc.
>>> > >
>>> > > One issue here is these actions have to be manually registered with
>>> the
>>> > > users account, but can not be initiated by applications themselves.
>>> As an
>>> > > example it may not be required by all users to verify their email,
>>> but
>>> > only
>>> > > when they use specific applications.
>>> > >
>>> > > Keycloak also needs to initiate actions from the account management
>>> > > console. Examples: updating email address should require verifying
>>> the
>>> > > email, configuring OTP, etc.
>>> > >
>>> > > With that in mind we are proposing to introduce Application Initiated
>>> > > Actions. An Application Initiated Action behind the scenes is just a
>>> > > Required Action, but it is initiated by an application and depending
>>> on
>>> > the
>>> > > action may be optional for the user to complete (where the user can
>>> > select
>>> > > cancel which would return the user back to the application).
>>> > >
>>> > > No Application Initiated Actions should perform any updates to the
>>> users
>>> > > account without prompting the user first. For example an application
>>> > > initiated action that is used to link an existing account to a social
>>> > > provider should ask the user first if they want to link to the
>>> provider.
>>> > >
>>> > > To make it easy for applications to integrate these I would like to
>>> > > leverage the standard OAuth flows that applications use to
>>> authenticate
>>> > > users. So to initiate verify-email action the application would
>>> redirect
>>> > to
>>> > > the authentication endpoint and add kc_action=<action alias> query
>>> > > parameter.
>>> > >
>>> > > One open question I have right now is. Assuming all Application
>>> Initiated
>>> > > Actions always prompt the user first do we need to add some
>>> mechanism in
>>> > > place to restrict what clients/applications are permitted to
>>> initiate an
>>> > > action? Requiring that would make it harder to use for applications.
>>> > >
>>> > > One thing I would also like to add is the ability for an Application
>>> > > Initiated Action to require the user to re-authenticate prior to
>>> > performing
>>> > > the action. For example update password should require the user to
>>> enter
>>> > > the current password, while verify email should not (as it simply
>>> sends
>>> > an
>>> > > email with a link to continue).
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Wed Mar  6 11:30:29 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Mar 2019 17:30:29 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
Message-ID: <CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>

Why do you think authentication/authorization is required? The user will be
prompted before making an action and it's an action they do against RH-SSO
and not automatically visible/exposed to the client.

On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com> wrote:

> One way is to follow authorization code constraints like checking the
> client_id and redirect_uri (assuming the user will be redirected back after
> the action completes). But still, we could also add some level
> authorization.
>

authorization code constraints doesn't work as anyone can just use the
client_id and redirect_uri from a different client.

Only viable option I can think of is to add an endpoint where the
application can request a token to initate an action. So flow would be:

1. App sends POST { action: <action-id> } with ID Token as bearer token in
header to a new endpoint. This would return a single use token.
2. App can now do the redirect protocol as before, but instead of
"?action=<action>" they would do "?action-token=<action token>"

In the JS adapter we can add a action(actionId) function that would get the
action token before redirecting the user.

Not sure what you mean about level authorization.


>
> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> The issue is more around how to authenticate clients and also the fact
>> that clients wanting to initiate actions may be public clients. We also
>> don't want to invent a new protocol for this, but rather just rely on the
>> OIDC flows.
>>
>> So with those constraints how would you authenticate the client?
>>
>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> IMO, we should have some level of authorization for clients initiating
>>> an action. This could be as simple as leveraging authz in order to define
>>> white/black lists of clients. Similar to what a KC extension does in
>>> regards to authentication.
>>>
>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Was hoping for some more feedback from the list on this one.
>>>>
>>>> Especially around not having any authentication of the clients wanting
>>>> to
>>>> initiate an action. I feel reasonable comfortable about not securing it
>>>> and
>>>> requiring actions to prompt the user before doing anything, but welcome
>>>> others opinion on it.
>>>>
>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>>>>
>>>> > Since there is no "silent" application initiated action (always
>>>> > prompts user) possible and actions are predefined at keycloak I see no
>>>> > need for the client/application restriction mechanism.
>>>> >
>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <sthorger at redhat.com
>>>> >
>>>> > wrote:
>>>> > >
>>>> > > Keycloak currently has required actions that are used to prompt the
>>>> user
>>>> > to
>>>> > > perform an action associated with their account after
>>>> authenticating, but
>>>> > > prior to being redirected to the application.
>>>> > >
>>>> > > Examples include: configure OTP, update profile, validate email,
>>>> etc.
>>>> > >
>>>> > > One issue here is these actions have to be manually registered with
>>>> the
>>>> > > users account, but can not be initiated by applications themselves.
>>>> As an
>>>> > > example it may not be required by all users to verify their email,
>>>> but
>>>> > only
>>>> > > when they use specific applications.
>>>> > >
>>>> > > Keycloak also needs to initiate actions from the account management
>>>> > > console. Examples: updating email address should require verifying
>>>> the
>>>> > > email, configuring OTP, etc.
>>>> > >
>>>> > > With that in mind we are proposing to introduce Application
>>>> Initiated
>>>> > > Actions. An Application Initiated Action behind the scenes is just a
>>>> > > Required Action, but it is initiated by an application and
>>>> depending on
>>>> > the
>>>> > > action may be optional for the user to complete (where the user can
>>>> > select
>>>> > > cancel which would return the user back to the application).
>>>> > >
>>>> > > No Application Initiated Actions should perform any updates to the
>>>> users
>>>> > > account without prompting the user first. For example an application
>>>> > > initiated action that is used to link an existing account to a
>>>> social
>>>> > > provider should ask the user first if they want to link to the
>>>> provider.
>>>> > >
>>>> > > To make it easy for applications to integrate these I would like to
>>>> > > leverage the standard OAuth flows that applications use to
>>>> authenticate
>>>> > > users. So to initiate verify-email action the application would
>>>> redirect
>>>> > to
>>>> > > the authentication endpoint and add kc_action=<action alias> query
>>>> > > parameter.
>>>> > >
>>>> > > One open question I have right now is. Assuming all Application
>>>> Initiated
>>>> > > Actions always prompt the user first do we need to add some
>>>> mechanism in
>>>> > > place to restrict what clients/applications are permitted to
>>>> initiate an
>>>> > > action? Requiring that would make it harder to use for applications.
>>>> > >
>>>> > > One thing I would also like to add is the ability for an Application
>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>> > performing
>>>> > > the action. For example update password should require the user to
>>>> enter
>>>> > > the current password, while verify email should not (as it simply
>>>> sends
>>>> > an
>>>> > > email with a link to continue).
>>>> > > _______________________________________________
>>>> > > keycloak-dev mailing list
>>>> > > keycloak-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From sthorger at redhat.com  Wed Mar  6 11:31:00 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Mar 2019 17:31:00 +0100
Subject: [keycloak-dev] Multi Tenant Support
In-Reply-To: <CA+YA1yJ2ABStQ=87Ymn=+6cLuOzf5y5rG09PVL-M22JkCbpzWg@mail.gmail.com>
References: <CA+YA1yJ2ABStQ=87Ymn=+6cLuOzf5y5rG09PVL-M22JkCbpzWg@mail.gmail.com>
Message-ID: <CAJgngAeSrs+GND63EbeQxeg0L=2Ha-6ms6xZPbSL3W94Zdxf9Q@mail.gmail.com>

Hi,

This ML is for developers and contributors. For questions and help please
use the user mailing list.

On Wed, 6 Mar 2019 at 12:26, Babji Kundateeri <kundateeri.babji at gmail.com>
wrote:

> Hi Team,
>
> We have a application with multi tenant system which uses simple form based
> authentication.
>
> Now we are planning to adopt keycloak to our system to have our own idp to
> get more flexibility of authentication.
>
> Our plan is to create a Realm for each customer is it fine to go with ?
>
> Can you suggest me a way forward / best approach to solve this problem?
>
> --
> Kind Regards,
> Babji Kundateeri.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Wed Mar  6 11:39:20 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Mar 2019 13:39:20 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
Message-ID: <CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>

On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com> wrote:

> Why do you think authentication/authorization is required? The user will
> be prompted before making an action and it's an action they do against
> RH-SSO and not automatically visible/exposed to the client.
>

The client is making the request and even though the user is at the
Keycloak server to perform the action, admins may want to restrict which
clients are allowed to perform such actions. That is what I mean by some
level of authorization.

You could even consider not authenticating the client at all, but still
allow admins to enforce which clients should be allowed to initiate actions
on the server.


>
> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> One way is to follow authorization code constraints like checking the
>> client_id and redirect_uri (assuming the user will be redirected back after
>> the action completes). But still, we could also add some level
>> authorization.
>>
>
> authorization code constraints doesn't work as anyone can just use the
> client_id and redirect_uri from a different client.
>

I may be missing the whole flow. I would ask then what happens after the
user performs an action. Is he/her redirected back to the client ? If so,
client_id + redirect_uri do work to make sure that the client is known and
that the user will be redirected back to a valid URI.


>
> Only viable option I can think of is to add an endpoint where the
> application can request a token to initate an action. So flow would be:
>
> 1. App sends POST { action: <action-id> } with ID Token as bearer token in
> header to a new endpoint. This would return a single use token.
> 2. App can now do the redirect protocol as before, but instead of
> "?action=<action>" they would do "?action-token=<action token>"
>
> In the JS adapter we can add a action(actionId) function that would get
> the action token before redirecting the user.
>
> Not sure what you mean about level authorization.
>
>
>>
>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> The issue is more around how to authenticate clients and also the fact
>>> that clients wanting to initiate actions may be public clients. We also
>>> don't want to invent a new protocol for this, but rather just rely on the
>>> OIDC flows.
>>>
>>> So with those constraints how would you authenticate the client?
>>>
>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> IMO, we should have some level of authorization for clients initiating
>>>> an action. This could be as simple as leveraging authz in order to define
>>>> white/black lists of clients. Similar to what a KC extension does in
>>>> regards to authentication.
>>>>
>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Was hoping for some more feedback from the list on this one.
>>>>>
>>>>> Especially around not having any authentication of the clients wanting
>>>>> to
>>>>> initiate an action. I feel reasonable comfortable about not securing
>>>>> it and
>>>>> requiring actions to prompt the user before doing anything, but welcome
>>>>> others opinion on it.
>>>>>
>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com> wrote:
>>>>>
>>>>> > Since there is no "silent" application initiated action (always
>>>>> > prompts user) possible and actions are predefined at keycloak I see
>>>>> no
>>>>> > need for the client/application restriction mechanism.
>>>>> >
>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>> sthorger at redhat.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > Keycloak currently has required actions that are used to prompt
>>>>> the user
>>>>> > to
>>>>> > > perform an action associated with their account after
>>>>> authenticating, but
>>>>> > > prior to being redirected to the application.
>>>>> > >
>>>>> > > Examples include: configure OTP, update profile, validate email,
>>>>> etc.
>>>>> > >
>>>>> > > One issue here is these actions have to be manually registered
>>>>> with the
>>>>> > > users account, but can not be initiated by applications
>>>>> themselves. As an
>>>>> > > example it may not be required by all users to verify their email,
>>>>> but
>>>>> > only
>>>>> > > when they use specific applications.
>>>>> > >
>>>>> > > Keycloak also needs to initiate actions from the account management
>>>>> > > console. Examples: updating email address should require verifying
>>>>> the
>>>>> > > email, configuring OTP, etc.
>>>>> > >
>>>>> > > With that in mind we are proposing to introduce Application
>>>>> Initiated
>>>>> > > Actions. An Application Initiated Action behind the scenes is just
>>>>> a
>>>>> > > Required Action, but it is initiated by an application and
>>>>> depending on
>>>>> > the
>>>>> > > action may be optional for the user to complete (where the user can
>>>>> > select
>>>>> > > cancel which would return the user back to the application).
>>>>> > >
>>>>> > > No Application Initiated Actions should perform any updates to the
>>>>> users
>>>>> > > account without prompting the user first. For example an
>>>>> application
>>>>> > > initiated action that is used to link an existing account to a
>>>>> social
>>>>> > > provider should ask the user first if they want to link to the
>>>>> provider.
>>>>> > >
>>>>> > > To make it easy for applications to integrate these I would like to
>>>>> > > leverage the standard OAuth flows that applications use to
>>>>> authenticate
>>>>> > > users. So to initiate verify-email action the application would
>>>>> redirect
>>>>> > to
>>>>> > > the authentication endpoint and add kc_action=<action alias> query
>>>>> > > parameter.
>>>>> > >
>>>>> > > One open question I have right now is. Assuming all Application
>>>>> Initiated
>>>>> > > Actions always prompt the user first do we need to add some
>>>>> mechanism in
>>>>> > > place to restrict what clients/applications are permitted to
>>>>> initiate an
>>>>> > > action? Requiring that would make it harder to use for
>>>>> applications.
>>>>> > >
>>>>> > > One thing I would also like to add is the ability for an
>>>>> Application
>>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>>> > performing
>>>>> > > the action. For example update password should require the user to
>>>>> enter
>>>>> > > the current password, while verify email should not (as it simply
>>>>> sends
>>>>> > an
>>>>> > > email with a link to continue).
>>>>> > > _______________________________________________
>>>>> > > keycloak-dev mailing list
>>>>> > > keycloak-dev at lists.jboss.org
>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> >
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From psilva at redhat.com  Wed Mar  6 11:51:55 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Mar 2019 13:51:55 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
Message-ID: <CAJrcDBcs=AcCj8Sghjr6t3JooBVH84ywu=_iQ3AAFaAySd1_=Q@mail.gmail.com>

Another thing that is not clear to me is how the client will know that
specific action was performed. Suppose that my client wants to ask the user
again for a password prior to entering some sensitive area in my
application. How I will check that the user did perform the action ?

On Wed, Mar 6, 2019 at 1:39 PM Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Why do you think authentication/authorization is required? The user will
>> be prompted before making an action and it's an action they do against
>> RH-SSO and not automatically visible/exposed to the client.
>>
>
> The client is making the request and even though the user is at the
> Keycloak server to perform the action, admins may want to restrict which
> clients are allowed to perform such actions. That is what I mean by some
> level of authorization.
>
> You could even consider not authenticating the client at all, but still
> allow admins to enforce which clients should be allowed to initiate actions
> on the server.
>
>
>>
>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> One way is to follow authorization code constraints like checking the
>>> client_id and redirect_uri (assuming the user will be redirected back after
>>> the action completes). But still, we could also add some level
>>> authorization.
>>>
>>
>> authorization code constraints doesn't work as anyone can just use the
>> client_id and redirect_uri from a different client.
>>
>
> I may be missing the whole flow. I would ask then what happens after the
> user performs an action. Is he/her redirected back to the client ? If so,
> client_id + redirect_uri do work to make sure that the client is known and
> that the user will be redirected back to a valid URI.
>
>
>>
>> Only viable option I can think of is to add an endpoint where the
>> application can request a token to initate an action. So flow would be:
>>
>> 1. App sends POST { action: <action-id> } with ID Token as bearer token
>> in header to a new endpoint. This would return a single use token.
>> 2. App can now do the redirect protocol as before, but instead of
>> "?action=<action>" they would do "?action-token=<action token>"
>>
>> In the JS adapter we can add a action(actionId) function that would get
>> the action token before redirecting the user.
>>
>> Not sure what you mean about level authorization.
>>
>>
>>>
>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> The issue is more around how to authenticate clients and also the fact
>>>> that clients wanting to initiate actions may be public clients. We also
>>>> don't want to invent a new protocol for this, but rather just rely on the
>>>> OIDC flows.
>>>>
>>>> So with those constraints how would you authenticate the client?
>>>>
>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>> IMO, we should have some level of authorization for clients initiating
>>>>> an action. This could be as simple as leveraging authz in order to define
>>>>> white/black lists of clients. Similar to what a KC extension does in
>>>>> regards to authentication.
>>>>>
>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>
>>>>>> Especially around not having any authentication of the clients
>>>>>> wanting to
>>>>>> initiate an action. I feel reasonable comfortable about not securing
>>>>>> it and
>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>> welcome
>>>>>> others opinion on it.
>>>>>>
>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Since there is no "silent" application initiated action (always
>>>>>> > prompts user) possible and actions are predefined at keycloak I see
>>>>>> no
>>>>>> > need for the client/application restriction mechanism.
>>>>>> >
>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>> sthorger at redhat.com>
>>>>>> > wrote:
>>>>>> > >
>>>>>> > > Keycloak currently has required actions that are used to prompt
>>>>>> the user
>>>>>> > to
>>>>>> > > perform an action associated with their account after
>>>>>> authenticating, but
>>>>>> > > prior to being redirected to the application.
>>>>>> > >
>>>>>> > > Examples include: configure OTP, update profile, validate email,
>>>>>> etc.
>>>>>> > >
>>>>>> > > One issue here is these actions have to be manually registered
>>>>>> with the
>>>>>> > > users account, but can not be initiated by applications
>>>>>> themselves. As an
>>>>>> > > example it may not be required by all users to verify their
>>>>>> email, but
>>>>>> > only
>>>>>> > > when they use specific applications.
>>>>>> > >
>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>> management
>>>>>> > > console. Examples: updating email address should require
>>>>>> verifying the
>>>>>> > > email, configuring OTP, etc.
>>>>>> > >
>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>> Initiated
>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>> just a
>>>>>> > > Required Action, but it is initiated by an application and
>>>>>> depending on
>>>>>> > the
>>>>>> > > action may be optional for the user to complete (where the user
>>>>>> can
>>>>>> > select
>>>>>> > > cancel which would return the user back to the application).
>>>>>> > >
>>>>>> > > No Application Initiated Actions should perform any updates to
>>>>>> the users
>>>>>> > > account without prompting the user first. For example an
>>>>>> application
>>>>>> > > initiated action that is used to link an existing account to a
>>>>>> social
>>>>>> > > provider should ask the user first if they want to link to the
>>>>>> provider.
>>>>>> > >
>>>>>> > > To make it easy for applications to integrate these I would like
>>>>>> to
>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>> authenticate
>>>>>> > > users. So to initiate verify-email action the application would
>>>>>> redirect
>>>>>> > to
>>>>>> > > the authentication endpoint and add kc_action=<action alias> query
>>>>>> > > parameter.
>>>>>> > >
>>>>>> > > One open question I have right now is. Assuming all Application
>>>>>> Initiated
>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>> mechanism in
>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>> initiate an
>>>>>> > > action? Requiring that would make it harder to use for
>>>>>> applications.
>>>>>> > >
>>>>>> > > One thing I would also like to add is the ability for an
>>>>>> Application
>>>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>>>> > performing
>>>>>> > > the action. For example update password should require the user
>>>>>> to enter
>>>>>> > > the current password, while verify email should not (as it simply
>>>>>> sends
>>>>>> > an
>>>>>> > > email with a link to continue).
>>>>>> > > _______________________________________________
>>>>>> > > keycloak-dev mailing list
>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> >
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>

From sthorger at redhat.com  Wed Mar  6 13:45:25 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Mar 2019 19:45:25 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
Message-ID: <CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>

On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Why do you think authentication/authorization is required? The user will
>> be prompted before making an action and it's an action they do against
>> RH-SSO and not automatically visible/exposed to the client.
>>
>
> The client is making the request and even though the user is at the
> Keycloak server to perform the action, admins may want to restrict which
> clients are allowed to perform such actions. That is what I mean by some
> level of authorization.
>
> You could even consider not authenticating the client at all, but still
> allow admins to enforce which clients should be allowed to initiate actions
> on the server.
>

I can't see how enforcing which clients is allowed to initiate actions will
work without authenticating the client.


>
>
>>
>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> One way is to follow authorization code constraints like checking the
>>> client_id and redirect_uri (assuming the user will be redirected back after
>>> the action completes). But still, we could also add some level
>>> authorization.
>>>
>>
>> authorization code constraints doesn't work as anyone can just use the
>> client_id and redirect_uri from a different client.
>>
>
> I may be missing the whole flow. I would ask then what happens after the
> user performs an action. Is he/her redirected back to the client ? If so,
> client_id + redirect_uri do work to make sure that the client is known and
> that the user will be redirected back to a valid URI.
>

It's just a standard OAuth flow, so app would get new tokens. Say the user
hasn't entered a DOB in the profile and the client wants that, then they
can request the user to enter a DOB, which would then result in the DOB
being available in the token.


>
>
>>
>> Only viable option I can think of is to add an endpoint where the
>> application can request a token to initate an action. So flow would be:
>>
>> 1. App sends POST { action: <action-id> } with ID Token as bearer token
>> in header to a new endpoint. This would return a single use token.
>> 2. App can now do the redirect protocol as before, but instead of
>> "?action=<action>" they would do "?action-token=<action token>"
>>
>> In the JS adapter we can add a action(actionId) function that would get
>> the action token before redirecting the user.
>>
>> Not sure what you mean about level authorization.
>>
>>
>>>
>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> The issue is more around how to authenticate clients and also the fact
>>>> that clients wanting to initiate actions may be public clients. We also
>>>> don't want to invent a new protocol for this, but rather just rely on the
>>>> OIDC flows.
>>>>
>>>> So with those constraints how would you authenticate the client?
>>>>
>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>> IMO, we should have some level of authorization for clients initiating
>>>>> an action. This could be as simple as leveraging authz in order to define
>>>>> white/black lists of clients. Similar to what a KC extension does in
>>>>> regards to authentication.
>>>>>
>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>
>>>>>> Especially around not having any authentication of the clients
>>>>>> wanting to
>>>>>> initiate an action. I feel reasonable comfortable about not securing
>>>>>> it and
>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>> welcome
>>>>>> others opinion on it.
>>>>>>
>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Since there is no "silent" application initiated action (always
>>>>>> > prompts user) possible and actions are predefined at keycloak I see
>>>>>> no
>>>>>> > need for the client/application restriction mechanism.
>>>>>> >
>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>> sthorger at redhat.com>
>>>>>> > wrote:
>>>>>> > >
>>>>>> > > Keycloak currently has required actions that are used to prompt
>>>>>> the user
>>>>>> > to
>>>>>> > > perform an action associated with their account after
>>>>>> authenticating, but
>>>>>> > > prior to being redirected to the application.
>>>>>> > >
>>>>>> > > Examples include: configure OTP, update profile, validate email,
>>>>>> etc.
>>>>>> > >
>>>>>> > > One issue here is these actions have to be manually registered
>>>>>> with the
>>>>>> > > users account, but can not be initiated by applications
>>>>>> themselves. As an
>>>>>> > > example it may not be required by all users to verify their
>>>>>> email, but
>>>>>> > only
>>>>>> > > when they use specific applications.
>>>>>> > >
>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>> management
>>>>>> > > console. Examples: updating email address should require
>>>>>> verifying the
>>>>>> > > email, configuring OTP, etc.
>>>>>> > >
>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>> Initiated
>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>> just a
>>>>>> > > Required Action, but it is initiated by an application and
>>>>>> depending on
>>>>>> > the
>>>>>> > > action may be optional for the user to complete (where the user
>>>>>> can
>>>>>> > select
>>>>>> > > cancel which would return the user back to the application).
>>>>>> > >
>>>>>> > > No Application Initiated Actions should perform any updates to
>>>>>> the users
>>>>>> > > account without prompting the user first. For example an
>>>>>> application
>>>>>> > > initiated action that is used to link an existing account to a
>>>>>> social
>>>>>> > > provider should ask the user first if they want to link to the
>>>>>> provider.
>>>>>> > >
>>>>>> > > To make it easy for applications to integrate these I would like
>>>>>> to
>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>> authenticate
>>>>>> > > users. So to initiate verify-email action the application would
>>>>>> redirect
>>>>>> > to
>>>>>> > > the authentication endpoint and add kc_action=<action alias> query
>>>>>> > > parameter.
>>>>>> > >
>>>>>> > > One open question I have right now is. Assuming all Application
>>>>>> Initiated
>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>> mechanism in
>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>> initiate an
>>>>>> > > action? Requiring that would make it harder to use for
>>>>>> applications.
>>>>>> > >
>>>>>> > > One thing I would also like to add is the ability for an
>>>>>> Application
>>>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>>>> > performing
>>>>>> > > the action. For example update password should require the user
>>>>>> to enter
>>>>>> > > the current password, while verify email should not (as it simply
>>>>>> sends
>>>>>> > an
>>>>>> > > email with a link to continue).
>>>>>> > > _______________________________________________
>>>>>> > > keycloak-dev mailing list
>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> >
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>

From sthorger at redhat.com  Thu Mar  7 04:03:16 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 10:03:16 +0100
Subject: [keycloak-dev] Moving container images to Quay (from Docker Hub)
Message-ID: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>

We are planning on moving our container images to Quay.io. The question is
do we also need to keep pushing to Docker Hub? If so why?

From thomas.darimont at googlemail.com  Thu Mar  7 04:07:08 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 7 Mar 2019 10:07:08 +0100
Subject: [keycloak-dev] Moving container images to Quay (from Docker Hub)
In-Reply-To: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>
References: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>
Message-ID: <CAK-7U1h4Z5=7Sc_98mfPDfvGOJEoVQa6VqXyq5WU=aRae5yQ+w@mail.gmail.com>

What's the reason for moving to Quay?

Cheers,
Thomas

Stian Thorgersen <sthorger at redhat.com> schrieb am Do., 7. M?rz 2019, 10:04:

> We are planning on moving our container images to Quay.io. The question is
> do we also need to keep pushing to Docker Hub? If so why?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Mar  7 06:12:36 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 12:12:36 +0100
Subject: [keycloak-dev] Moving container images to Quay (from Docker Hub)
In-Reply-To: <CAK-7U1h4Z5=7Sc_98mfPDfvGOJEoVQa6VqXyq5WU=aRae5yQ+w@mail.gmail.com>
References: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>
	<CAK-7U1h4Z5=7Sc_98mfPDfvGOJEoVQa6VqXyq5WU=aRae5yQ+w@mail.gmail.com>
Message-ID: <CAJgngAcsfC79+8LhpTu9LXcjOs-gc9Cjf3qzE+_VCsk1dZjmsQ@mail.gmail.com>

Docker has gained too much ownership around containers. Red Hat is doing a
lot of investments around improving that to give people flexibility and
choices when it comes to containers. This includes Podman, Buildah and
Quay.io. That being said it is obviously still important for us that
container images are still available to those that choose to use Docker
tools, so we will make sure you still can docker run keycloak.

Any reason why not Quay?! ;)

On Thu, 7 Mar 2019 at 10:07, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> What's the reason for moving to Quay?
>
> Cheers,
> Thomas
>
> Stian Thorgersen <sthorger at redhat.com> schrieb am Do., 7. M?rz 2019,
> 10:04:
>
>> We are planning on moving our container images to Quay.io. The question is
>> do we also need to keep pushing to Docker Hub? If so why?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Thu Mar  7 06:14:42 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 12:14:42 +0100
Subject: [keycloak-dev] Moving container images to Quay (from Docker Hub)
In-Reply-To: <CAJgngAcsfC79+8LhpTu9LXcjOs-gc9Cjf3qzE+_VCsk1dZjmsQ@mail.gmail.com>
References: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>
	<CAK-7U1h4Z5=7Sc_98mfPDfvGOJEoVQa6VqXyq5WU=aRae5yQ+w@mail.gmail.com>
	<CAJgngAcsfC79+8LhpTu9LXcjOs-gc9Cjf3qzE+_VCsk1dZjmsQ@mail.gmail.com>
Message-ID: <CAJgngAd7xWA_AsXHiOGoyKQ1bq0MCHZ_Yp=w78=1rt1Sqq1dOg@mail.gmail.com>

Right now the images are available both on Quay and Docker Hub. With
potentially removing Docker Hub in the future.

You can find the images in Quay here:
https://quay.io/organization/keycloak

In Quay it's keycloak/keycloak instead of jboss/keycloak as we do want to
get away from the false impression that Keycloak is only for Java stuff.

On Thu, 7 Mar 2019 at 12:12, Stian Thorgersen <sthorger at redhat.com> wrote:

> Docker has gained too much ownership around containers. Red Hat is doing a
> lot of investments around improving that to give people flexibility and
> choices when it comes to containers. This includes Podman, Buildah and
> Quay.io. That being said it is obviously still important for us that
> container images are still available to those that choose to use Docker
> tools, so we will make sure you still can docker run keycloak.
>
> Any reason why not Quay?! ;)
>
> On Thu, 7 Mar 2019 at 10:07, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> What's the reason for moving to Quay?
>>
>> Cheers,
>> Thomas
>>
>> Stian Thorgersen <sthorger at redhat.com> schrieb am Do., 7. M?rz 2019,
>> 10:04:
>>
>>> We are planning on moving our container images to Quay.io. The question
>>> is
>>> do we also need to keep pushing to Docker Hub? If so why?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Thu Mar  7 06:16:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 12:16:13 +0100
Subject: [keycloak-dev] Moving container images to Quay (from Docker Hub)
In-Reply-To: <CAJgngAd7xWA_AsXHiOGoyKQ1bq0MCHZ_Yp=w78=1rt1Sqq1dOg@mail.gmail.com>
References: <CAJgngAfHw2r8iroNuNDANVeq+f4dmYEAOzXf_626Cak3A7=ZsA@mail.gmail.com>
	<CAK-7U1h4Z5=7Sc_98mfPDfvGOJEoVQa6VqXyq5WU=aRae5yQ+w@mail.gmail.com>
	<CAJgngAcsfC79+8LhpTu9LXcjOs-gc9Cjf3qzE+_VCsk1dZjmsQ@mail.gmail.com>
	<CAJgngAd7xWA_AsXHiOGoyKQ1bq0MCHZ_Yp=w78=1rt1Sqq1dOg@mail.gmail.com>
Message-ID: <CAJgngAc9rm9XNeoYnRoyCc=s0vP1qLUBOAktUDPv_p3w6X2k0A@mail.gmail.com>

>From my impression most distros already pull images from quay
automatically, so there shouldn't be any change for the user. For those few
that don't have distros where it pulls from quay the images can be pulled
with docker pull quay.io/keycloak/keycloak

On Thu, 7 Mar 2019 at 12:14, Stian Thorgersen <sthorger at redhat.com> wrote:

> Right now the images are available both on Quay and Docker Hub. With
> potentially removing Docker Hub in the future.
>
> You can find the images in Quay here:
> https://quay.io/organization/keycloak
>
> In Quay it's keycloak/keycloak instead of jboss/keycloak as we do want to
> get away from the false impression that Keycloak is only for Java stuff.
>
> On Thu, 7 Mar 2019 at 12:12, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Docker has gained too much ownership around containers. Red Hat is doing
>> a lot of investments around improving that to give people flexibility and
>> choices when it comes to containers. This includes Podman, Buildah and
>> Quay.io. That being said it is obviously still important for us that
>> container images are still available to those that choose to use Docker
>> tools, so we will make sure you still can docker run keycloak.
>>
>> Any reason why not Quay?! ;)
>>
>> On Thu, 7 Mar 2019 at 10:07, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> What's the reason for moving to Quay?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> Stian Thorgersen <sthorger at redhat.com> schrieb am Do., 7. M?rz 2019,
>>> 10:04:
>>>
>>>> We are planning on moving our container images to Quay.io. The question
>>>> is
>>>> do we also need to keep pushing to Docker Hub? If so why?
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From psilva at redhat.com  Thu Mar  7 07:39:20 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 7 Mar 2019 09:39:20 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
Message-ID: <CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>

On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Why do you think authentication/authorization is required? The user will
>>> be prompted before making an action and it's an action they do against
>>> RH-SSO and not automatically visible/exposed to the client.
>>>
>>
>> The client is making the request and even though the user is at the
>> Keycloak server to perform the action, admins may want to restrict which
>> clients are allowed to perform such actions. That is what I mean by some
>> level of authorization.
>>
>> You could even consider not authenticating the client at all, but still
>> allow admins to enforce which clients should be allowed to initiate actions
>> on the server.
>>
>
> I can't see how enforcing which clients is allowed to initiate actions
> will work without authenticating the client.
>

Maybe the word authenticate seems too much to what we are discussing. This
is more a validation of the client making the request. Considering that,
I'm saying that you could just rely on client_id and redirect uris (the
client is already authenticated and if doing browser authentication the
cookie is already present) and possibly add some level of authorization to
enforce which clients can perform actions (instead of just relying on the
authenticated session). Redirect uris are really important because you want
to make sure the redirect uri is valid before redirecting the user.


>
>
>>
>>
>>>
>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> One way is to follow authorization code constraints like checking the
>>>> client_id and redirect_uri (assuming the user will be redirected back after
>>>> the action completes). But still, we could also add some level
>>>> authorization.
>>>>
>>>
>>> authorization code constraints doesn't work as anyone can just use the
>>> client_id and redirect_uri from a different client.
>>>
>>
>> I may be missing the whole flow. I would ask then what happens after the
>> user performs an action. Is he/her redirected back to the client ? If so,
>> client_id + redirect_uri do work to make sure that the client is known and
>> that the user will be redirected back to a valid URI.
>>
>
> It's just a standard OAuth flow, so app would get new tokens. Say the user
> hasn't entered a DOB in the profile and the client wants that, then they
> can request the user to enter a DOB, which would then result in the DOB
> being available in the token.
>

This flow seems very closely related with the Claims Gathering Flow from
UMA specs. We could probably review what is there and see if it can help to
solve this problem of app initiated actions.


>
>
>>
>>
>>>
>>> Only viable option I can think of is to add an endpoint where the
>>> application can request a token to initate an action. So flow would be:
>>>
>>> 1. App sends POST { action: <action-id> } with ID Token as bearer token
>>> in header to a new endpoint. This would return a single use token.
>>> 2. App can now do the redirect protocol as before, but instead of
>>> "?action=<action>" they would do "?action-token=<action token>"
>>>
>>> In the JS adapter we can add a action(actionId) function that would get
>>> the action token before redirecting the user.
>>>
>>> Not sure what you mean about level authorization.
>>>
>>>
>>>>
>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> The issue is more around how to authenticate clients and also the fact
>>>>> that clients wanting to initiate actions may be public clients. We also
>>>>> don't want to invent a new protocol for this, but rather just rely on the
>>>>> OIDC flows.
>>>>>
>>>>> So with those constraints how would you authenticate the client?
>>>>>
>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> IMO, we should have some level of authorization for clients
>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>> in regards to authentication.
>>>>>>
>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>
>>>>>>> Especially around not having any authentication of the clients
>>>>>>> wanting to
>>>>>>> initiate an action. I feel reasonable comfortable about not securing
>>>>>>> it and
>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>> welcome
>>>>>>> others opinion on it.
>>>>>>>
>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Since there is no "silent" application initiated action (always
>>>>>>> > prompts user) possible and actions are predefined at keycloak I
>>>>>>> see no
>>>>>>> > need for the client/application restriction mechanism.
>>>>>>> >
>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>> sthorger at redhat.com>
>>>>>>> > wrote:
>>>>>>> > >
>>>>>>> > > Keycloak currently has required actions that are used to prompt
>>>>>>> the user
>>>>>>> > to
>>>>>>> > > perform an action associated with their account after
>>>>>>> authenticating, but
>>>>>>> > > prior to being redirected to the application.
>>>>>>> > >
>>>>>>> > > Examples include: configure OTP, update profile, validate email,
>>>>>>> etc.
>>>>>>> > >
>>>>>>> > > One issue here is these actions have to be manually registered
>>>>>>> with the
>>>>>>> > > users account, but can not be initiated by applications
>>>>>>> themselves. As an
>>>>>>> > > example it may not be required by all users to verify their
>>>>>>> email, but
>>>>>>> > only
>>>>>>> > > when they use specific applications.
>>>>>>> > >
>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>> management
>>>>>>> > > console. Examples: updating email address should require
>>>>>>> verifying the
>>>>>>> > > email, configuring OTP, etc.
>>>>>>> > >
>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>> Initiated
>>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>>> just a
>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>> depending on
>>>>>>> > the
>>>>>>> > > action may be optional for the user to complete (where the user
>>>>>>> can
>>>>>>> > select
>>>>>>> > > cancel which would return the user back to the application).
>>>>>>> > >
>>>>>>> > > No Application Initiated Actions should perform any updates to
>>>>>>> the users
>>>>>>> > > account without prompting the user first. For example an
>>>>>>> application
>>>>>>> > > initiated action that is used to link an existing account to a
>>>>>>> social
>>>>>>> > > provider should ask the user first if they want to link to the
>>>>>>> provider.
>>>>>>> > >
>>>>>>> > > To make it easy for applications to integrate these I would like
>>>>>>> to
>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>> authenticate
>>>>>>> > > users. So to initiate verify-email action the application would
>>>>>>> redirect
>>>>>>> > to
>>>>>>> > > the authentication endpoint and add kc_action=<action alias>
>>>>>>> query
>>>>>>> > > parameter.
>>>>>>> > >
>>>>>>> > > One open question I have right now is. Assuming all Application
>>>>>>> Initiated
>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>> mechanism in
>>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>>> initiate an
>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>> applications.
>>>>>>> > >
>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>> Application
>>>>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>>>>> > performing
>>>>>>> > > the action. For example update password should require the user
>>>>>>> to enter
>>>>>>> > > the current password, while verify email should not (as it
>>>>>>> simply sends
>>>>>>> > an
>>>>>>> > > email with a link to continue).
>>>>>>> > > _______________________________________________
>>>>>>> > > keycloak-dev mailing list
>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>> > > https://lists.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 dhardiker at adaptavist.com  Thu Mar  7 08:38:36 2019
From: dhardiker at adaptavist.com (Dan Hardiker)
Date: Thu, 7 Mar 2019 13:38:36 +0000
Subject: [keycloak-dev] Password Expiry present but unimplemented?
Message-ID: <2BD19E73-9A8B-4891-BA3B-D67BAD5ED81E@adaptavist.com>

Hi,

I noticed that password expiry wasn?t working with LDAP. Initially I thought this was another mapping issue, expecting to need to support a passwordSetAt timestamp or something, however when I dug into the code I found ForceExpiredPasswordPolicyProviderFactory had the following:

@Override
public PolicyError validate(RealmModel realm, UserModel user, String password) {
    return null;
}

@Override
public PolicyError validate(String user, String password) {
    return null;
}

This appears to mean it?s not implemented. Is this the case? Am I looking in the wrong place?


?
Dan Hardiker | Adaptavist
dhardiker at adaptavist.com
 
Winners of the Atlassian President's Award for Technical Excellence - http://bit.ly/techexc <http://bit.ly/techexc>

Adaptavist <http://adaptavist.com/>, Waterside, Unit 2, 44-48 Wharf Road, London, N1 7UX, United Kingdom.
Registered in England and Wales #5456785.


From sthorger at redhat.com  Thu Mar  7 10:13:48 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 16:13:48 +0100
Subject: [keycloak-dev] Password Expiry present but unimplemented?
In-Reply-To: <2BD19E73-9A8B-4891-BA3B-D67BAD5ED81E@adaptavist.com>
References: <2BD19E73-9A8B-4891-BA3B-D67BAD5ED81E@adaptavist.com>
Message-ID: <CAJgngAcDMRo6d36nWuEG4p5Dcb1Md0QwJeLb0ehKL4DrhgspGQ@mail.gmail.com>

I don't know the exact code, but I suspect
ForceExpiredPasswordPolicyProviderFactory is just there to make it possible
to configure. PasswordPolicy providers in general take action when a
password is updated, not when it's used. As such there is probably
something else that is checking the password is not expired, probably
something hardcoded in the authenticator.

On Thu, 7 Mar 2019 at 14:49, Dan Hardiker <dhardiker at adaptavist.com> wrote:

> Hi,
>
> I noticed that password expiry wasn?t working with LDAP. Initially I
> thought this was another mapping issue, expecting to need to support a
> passwordSetAt timestamp or something, however when I dug into the code I
> found ForceExpiredPasswordPolicyProviderFactory had the following:
>
> @Override
> public PolicyError validate(RealmModel realm, UserModel user, String
> password) {
>     return null;
> }
>
> @Override
> public PolicyError validate(String user, String password) {
>     return null;
> }
>
> This appears to mean it?s not implemented. Is this the case? Am I looking
> in the wrong place?
>
>
> ?
> Dan Hardiker | Adaptavist
> dhardiker at adaptavist.com
>
> Winners of the Atlassian President's Award for Technical Excellence -
> http://bit.ly/techexc <http://bit.ly/techexc>
>
> Adaptavist <http://adaptavist.com/>, Waterside, Unit 2, 44-48 Wharf Road,
> London, N1 7UX, United Kingdom.
> Registered in England and Wales #5456785.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Thu Mar  7 10:19:45 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 16:19:45 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
Message-ID: <CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>

On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Why do you think authentication/authorization is required? The user
>>>> will be prompted before making an action and it's an action they do against
>>>> RH-SSO and not automatically visible/exposed to the client.
>>>>
>>>
>>> The client is making the request and even though the user is at the
>>> Keycloak server to perform the action, admins may want to restrict which
>>> clients are allowed to perform such actions. That is what I mean by some
>>> level of authorization.
>>>
>>> You could even consider not authenticating the client at all, but still
>>> allow admins to enforce which clients should be allowed to initiate actions
>>> on the server.
>>>
>>
>> I can't see how enforcing which clients is allowed to initiate actions
>> will work without authenticating the client.
>>
>
> Maybe the word authenticate seems too much to what we are discussing. This
> is more a validation of the client making the request. Considering that,
> I'm saying that you could just rely on client_id and redirect uris (the
> client is already authenticated and if doing browser authentication the
> cookie is already present) and possibly add some level of authorization to
> enforce which clients can perform actions (instead of just relying on the
> authenticated session). Redirect uris are really important because you want
> to make sure the redirect uri is valid before redirecting the user.
>

The plan is to use the auth endpoint, so client_id and redirect_uris are
already being checked. It's just a standard OAuth flow.

IMO that's fine as long as there's no need to limit what clients can
initiate actions. If that's needed then we need something more complicated
that properly authenticates the client, as anyone could just use the
client_id and redirect_uri from a different application to get the action
initiated (although wouldn't then have the user redirected back to the app
of course).


>
>
>>
>>
>>>
>>>
>>>>
>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>> One way is to follow authorization code constraints like checking the
>>>>> client_id and redirect_uri (assuming the user will be redirected back after
>>>>> the action completes). But still, we could also add some level
>>>>> authorization.
>>>>>
>>>>
>>>> authorization code constraints doesn't work as anyone can just use the
>>>> client_id and redirect_uri from a different client.
>>>>
>>>
>>> I may be missing the whole flow. I would ask then what happens after the
>>> user performs an action. Is he/her redirected back to the client ? If so,
>>> client_id + redirect_uri do work to make sure that the client is known and
>>> that the user will be redirected back to a valid URI.
>>>
>>
>> It's just a standard OAuth flow, so app would get new tokens. Say the
>> user hasn't entered a DOB in the profile and the client wants that, then
>> they can request the user to enter a DOB, which would then result in the
>> DOB being available in the token.
>>
>
> This flow seems very closely related with the Claims Gathering Flow from
> UMA specs. We could probably review what is there and see if it can help to
> solve this problem of app initiated actions.
>

Go for it ;)


>
>

>
>>
>>
>>>
>>>
>>>>
>>>> Only viable option I can think of is to add an endpoint where the
>>>> application can request a token to initate an action. So flow would be:
>>>>
>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer token
>>>> in header to a new endpoint. This would return a single use token.
>>>> 2. App can now do the redirect protocol as before, but instead of
>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>
>>>> In the JS adapter we can add a action(actionId) function that would get
>>>> the action token before redirecting the user.
>>>>
>>>> Not sure what you mean about level authorization.
>>>>
>>>>
>>>>>
>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> The issue is more around how to authenticate clients and also the
>>>>>> fact that clients wanting to initiate actions may be public clients. We
>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>> the OIDC flows.
>>>>>>
>>>>>> So with those constraints how would you authenticate the client?
>>>>>>
>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>> in regards to authentication.
>>>>>>>
>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>
>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>> wanting to
>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>> securing it and
>>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>>> welcome
>>>>>>>> others opinion on it.
>>>>>>>>
>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Since there is no "silent" application initiated action (always
>>>>>>>> > prompts user) possible and actions are predefined at keycloak I
>>>>>>>> see no
>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>> >
>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com>
>>>>>>>> > wrote:
>>>>>>>> > >
>>>>>>>> > > Keycloak currently has required actions that are used to prompt
>>>>>>>> the user
>>>>>>>> > to
>>>>>>>> > > perform an action associated with their account after
>>>>>>>> authenticating, but
>>>>>>>> > > prior to being redirected to the application.
>>>>>>>> > >
>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>> email, etc.
>>>>>>>> > >
>>>>>>>> > > One issue here is these actions have to be manually registered
>>>>>>>> with the
>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>> themselves. As an
>>>>>>>> > > example it may not be required by all users to verify their
>>>>>>>> email, but
>>>>>>>> > only
>>>>>>>> > > when they use specific applications.
>>>>>>>> > >
>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>> management
>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>> verifying the
>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>> > >
>>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>>> Initiated
>>>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>>>> just a
>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>> depending on
>>>>>>>> > the
>>>>>>>> > > action may be optional for the user to complete (where the user
>>>>>>>> can
>>>>>>>> > select
>>>>>>>> > > cancel which would return the user back to the application).
>>>>>>>> > >
>>>>>>>> > > No Application Initiated Actions should perform any updates to
>>>>>>>> the users
>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>> application
>>>>>>>> > > initiated action that is used to link an existing account to a
>>>>>>>> social
>>>>>>>> > > provider should ask the user first if they want to link to the
>>>>>>>> provider.
>>>>>>>> > >
>>>>>>>> > > To make it easy for applications to integrate these I would
>>>>>>>> like to
>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>> authenticate
>>>>>>>> > > users. So to initiate verify-email action the application would
>>>>>>>> redirect
>>>>>>>> > to
>>>>>>>> > > the authentication endpoint and add kc_action=<action alias>
>>>>>>>> query
>>>>>>>> > > parameter.
>>>>>>>> > >
>>>>>>>> > > One open question I have right now is. Assuming all Application
>>>>>>>> Initiated
>>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>>> mechanism in
>>>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>>>> initiate an
>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>> applications.
>>>>>>>> > >
>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>> Application
>>>>>>>> > > Initiated Action to require the user to re-authenticate prior to
>>>>>>>> > performing
>>>>>>>> > > the action. For example update password should require the user
>>>>>>>> to enter
>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>> simply sends
>>>>>>>> > an
>>>>>>>> > > email with a link to continue).
>>>>>>>> > > _______________________________________________
>>>>>>>> > > keycloak-dev mailing list
>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>

From sthorger at redhat.com  Thu Mar  7 10:33:24 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Mar 2019 16:33:24 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
Message-ID: <CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>

Is it this stuff you're thinking about:
https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect

>From that it does a get including the ticket as a query parameter. I don't
like the idea of sending tickets as query params as they could be logged.
For the application initiated action it would have to be an ID token sent
as the ticket. Or as I mentioned before perhaps we have a way of creating a
ticket that can only be used to initiate an action.

Perhaps what we could do is:

1. By default any application can initiate an action
1.1. To initiate an action there's no need for a ticket of any sort, just a
regular oauth flow
2. Later add support if demand to limit what applications can initiate
actions
2.1 Same as before if the action being initiated is open for everyone then
no need for a ticket
2.2 If the action being initiated is only permitted by some applications we
would need some form of authentication.

For 2.2 I have 3 suggestions in mind:

a. Just include id_token as a ticket query param like  UMA claim redirect
does
b. Add support to obtain an initiate action ticket from a endpoint using an
id token as bearer token
c. Add a note into client session with a initiate action ticket for clients
that can initiate actions and map this into the id token.

On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Why do you think authentication/authorization is required? The user
>>>>> will be prompted before making an action and it's an action they do against
>>>>> RH-SSO and not automatically visible/exposed to the client.
>>>>>
>>>>
>>>> The client is making the request and even though the user is at the
>>>> Keycloak server to perform the action, admins may want to restrict which
>>>> clients are allowed to perform such actions. That is what I mean by some
>>>> level of authorization.
>>>>
>>>> You could even consider not authenticating the client at all, but still
>>>> allow admins to enforce which clients should be allowed to initiate actions
>>>> on the server.
>>>>
>>>
>>> I can't see how enforcing which clients is allowed to initiate actions
>>> will work without authenticating the client.
>>>
>>
>> Maybe the word authenticate seems too much to what we are discussing.
>> This is more a validation of the client making the request. Considering
>> that, I'm saying that you could just rely on client_id and redirect uris
>> (the client is already authenticated and if doing browser authentication
>> the cookie is already present) and possibly add some level of authorization
>> to enforce which clients can perform actions (instead of just relying on
>> the authenticated session). Redirect uris are really important because you
>> want to make sure the redirect uri is valid before redirecting the user.
>>
>
> The plan is to use the auth endpoint, so client_id and redirect_uris are
> already being checked. It's just a standard OAuth flow.
>
> IMO that's fine as long as there's no need to limit what clients can
> initiate actions. If that's needed then we need something more complicated
> that properly authenticates the client, as anyone could just use the
> client_id and redirect_uri from a different application to get the action
> initiated (although wouldn't then have the user redirected back to the app
> of course).
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> One way is to follow authorization code constraints like checking the
>>>>>> client_id and redirect_uri (assuming the user will be redirected back after
>>>>>> the action completes). But still, we could also add some level
>>>>>> authorization.
>>>>>>
>>>>>
>>>>> authorization code constraints doesn't work as anyone can just use the
>>>>> client_id and redirect_uri from a different client.
>>>>>
>>>>
>>>> I may be missing the whole flow. I would ask then what happens after
>>>> the user performs an action. Is he/her redirected back to the client ? If
>>>> so, client_id + redirect_uri do work to make sure that the client is known
>>>> and that the user will be redirected back to a valid URI.
>>>>
>>>
>>> It's just a standard OAuth flow, so app would get new tokens. Say the
>>> user hasn't entered a DOB in the profile and the client wants that, then
>>> they can request the user to enter a DOB, which would then result in the
>>> DOB being available in the token.
>>>
>>
>> This flow seems very closely related with the Claims Gathering Flow from
>> UMA specs. We could probably review what is there and see if it can help to
>> solve this problem of app initiated actions.
>>
>
> Go for it ;)
>
>
>>
>>
>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Only viable option I can think of is to add an endpoint where the
>>>>> application can request a token to initate an action. So flow would be:
>>>>>
>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>> token in header to a new endpoint. This would return a single use token.
>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>
>>>>> In the JS adapter we can add a action(actionId) function that would
>>>>> get the action token before redirecting the user.
>>>>>
>>>>> Not sure what you mean about level authorization.
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The issue is more around how to authenticate clients and also the
>>>>>>> fact that clients wanting to initiate actions may be public clients. We
>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>> the OIDC flows.
>>>>>>>
>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>
>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>> in regards to authentication.
>>>>>>>>
>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>
>>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>>> wanting to
>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>> securing it and
>>>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>>>> welcome
>>>>>>>>> others opinion on it.
>>>>>>>>>
>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> > Since there is no "silent" application initiated action (always
>>>>>>>>> > prompts user) possible and actions are predefined at keycloak I
>>>>>>>>> see no
>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>> >
>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com>
>>>>>>>>> > wrote:
>>>>>>>>> > >
>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>> prompt the user
>>>>>>>>> > to
>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>> authenticating, but
>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>> > >
>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>> email, etc.
>>>>>>>>> > >
>>>>>>>>> > > One issue here is these actions have to be manually registered
>>>>>>>>> with the
>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>> themselves. As an
>>>>>>>>> > > example it may not be required by all users to verify their
>>>>>>>>> email, but
>>>>>>>>> > only
>>>>>>>>> > > when they use specific applications.
>>>>>>>>> > >
>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>> management
>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>> verifying the
>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>> > >
>>>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>>>> Initiated
>>>>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>>>>> just a
>>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>>> depending on
>>>>>>>>> > the
>>>>>>>>> > > action may be optional for the user to complete (where the
>>>>>>>>> user can
>>>>>>>>> > select
>>>>>>>>> > > cancel which would return the user back to the application).
>>>>>>>>> > >
>>>>>>>>> > > No Application Initiated Actions should perform any updates to
>>>>>>>>> the users
>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>> application
>>>>>>>>> > > initiated action that is used to link an existing account to a
>>>>>>>>> social
>>>>>>>>> > > provider should ask the user first if they want to link to the
>>>>>>>>> provider.
>>>>>>>>> > >
>>>>>>>>> > > To make it easy for applications to integrate these I would
>>>>>>>>> like to
>>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>>> authenticate
>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>> would redirect
>>>>>>>>> > to
>>>>>>>>> > > the authentication endpoint and add kc_action=<action alias>
>>>>>>>>> query
>>>>>>>>> > > parameter.
>>>>>>>>> > >
>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>> Application Initiated
>>>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>>>> mechanism in
>>>>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>>>>> initiate an
>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>> applications.
>>>>>>>>> > >
>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>> Application
>>>>>>>>> > > Initiated Action to require the user to re-authenticate prior
>>>>>>>>> to
>>>>>>>>> > performing
>>>>>>>>> > > the action. For example update password should require the
>>>>>>>>> user to enter
>>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>>> simply sends
>>>>>>>>> > an
>>>>>>>>> > > email with a link to continue).
>>>>>>>>> > > _______________________________________________
>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>

From psilva at redhat.com  Thu Mar  7 13:09:29 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 7 Mar 2019 15:09:29 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
Message-ID: <CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>

On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Is it this stuff you're thinking about:
>
> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>
> From that it does a get including the ticket as a query parameter. I don't
> like the idea of sending tickets as query params as they could be logged.
> For the application initiated action it would have to be an ID token sent
> as the ticket. Or as I mentioned before perhaps we have a way of creating a
> ticket that can only be used to initiate an action.
>

Why you need to send the id token if the client already got an id token
and, considering browser flow, there is a cookie that can be used by
Keycloak to identify the client/user ?


>
> Perhaps what we could do is:
>
> 1. By default any application can initiate an action
> 1.1. To initiate an action there's no need for a ticket of any sort, just
> a regular oauth flow
> 2. Later add support if demand to limit what applications can initiate
> actions
> 2.1 Same as before if the action being initiated is open for everyone then
> no need for a ticket
> 2.2 If the action being initiated is only permitted by some applications
> we would need some form of authentication.
>
> For 2.2 I have 3 suggestions in mind:
>
> a. Just include id_token as a ticket query param like  UMA claim redirect
> does
> b. Add support to obtain an initiate action ticket from a endpoint using
> an id token as bearer token
> c. Add a note into client session with a initiate action ticket for
> clients that can initiate actions and map this into the id token.
>

Not sure ...

If you think about it, the part interested in obtaining the claims after an
action is completed is not the client but the audience of the token, the
resource server. In this case, the UMA approach seems more appropriate
because the resource server is in control about what actions the client
should initiate in order to fulfill the constraints imposed by the resource
server to access its protected resources. Where these constraints could be
a DOB in the token or a higher security level.

The app initiating actions in the server is not the goal, but the tool to
obtain additional claims from the server ...

However, for some applications acting as both client and resource server
(e.g.: a monolithic jee) can avoid all the ticket dance and just redirect
the user to the server as you pointed out in 1.


>
> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Why do you think authentication/authorization is required? The user
>>>>>> will be prompted before making an action and it's an action they do against
>>>>>> RH-SSO and not automatically visible/exposed to the client.
>>>>>>
>>>>>
>>>>> The client is making the request and even though the user is at the
>>>>> Keycloak server to perform the action, admins may want to restrict which
>>>>> clients are allowed to perform such actions. That is what I mean by some
>>>>> level of authorization.
>>>>>
>>>>> You could even consider not authenticating the client at all, but
>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>> actions on the server.
>>>>>
>>>>
>>>> I can't see how enforcing which clients is allowed to initiate actions
>>>> will work without authenticating the client.
>>>>
>>>
>>> Maybe the word authenticate seems too much to what we are discussing.
>>> This is more a validation of the client making the request. Considering
>>> that, I'm saying that you could just rely on client_id and redirect uris
>>> (the client is already authenticated and if doing browser authentication
>>> the cookie is already present) and possibly add some level of authorization
>>> to enforce which clients can perform actions (instead of just relying on
>>> the authenticated session). Redirect uris are really important because you
>>> want to make sure the redirect uri is valid before redirecting the user.
>>>
>>
>> The plan is to use the auth endpoint, so client_id and redirect_uris are
>> already being checked. It's just a standard OAuth flow.
>>
>> IMO that's fine as long as there's no need to limit what clients can
>> initiate actions. If that's needed then we need something more complicated
>> that properly authenticates the client, as anyone could just use the
>> client_id and redirect_uri from a different application to get the action
>> initiated (although wouldn't then have the user redirected back to the app
>> of course).
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> One way is to follow authorization code constraints like checking
>>>>>>> the client_id and redirect_uri (assuming the user will be redirected back
>>>>>>> after the action completes). But still, we could also add some level
>>>>>>> authorization.
>>>>>>>
>>>>>>
>>>>>> authorization code constraints doesn't work as anyone can just use
>>>>>> the client_id and redirect_uri from a different client.
>>>>>>
>>>>>
>>>>> I may be missing the whole flow. I would ask then what happens after
>>>>> the user performs an action. Is he/her redirected back to the client ? If
>>>>> so, client_id + redirect_uri do work to make sure that the client is known
>>>>> and that the user will be redirected back to a valid URI.
>>>>>
>>>>
>>>> It's just a standard OAuth flow, so app would get new tokens. Say the
>>>> user hasn't entered a DOB in the profile and the client wants that, then
>>>> they can request the user to enter a DOB, which would then result in the
>>>> DOB being available in the token.
>>>>
>>>
>>> This flow seems very closely related with the Claims Gathering Flow from
>>> UMA specs. We could probably review what is there and see if it can help to
>>> solve this problem of app initiated actions.
>>>
>>
>> Go for it ;)
>>
>>
>>>
>>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Only viable option I can think of is to add an endpoint where the
>>>>>> application can request a token to initate an action. So flow would be:
>>>>>>
>>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>>> token in header to a new endpoint. This would return a single use token.
>>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>>
>>>>>> In the JS adapter we can add a action(actionId) function that would
>>>>>> get the action token before redirecting the user.
>>>>>>
>>>>>> Not sure what you mean about level authorization.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> The issue is more around how to authenticate clients and also the
>>>>>>>> fact that clients wanting to initiate actions may be public clients. We
>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>> the OIDC flows.
>>>>>>>>
>>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>>
>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>> in regards to authentication.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>
>>>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>>>> wanting to
>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>> securing it and
>>>>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>>>>> welcome
>>>>>>>>>> others opinion on it.
>>>>>>>>>>
>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> > Since there is no "silent" application initiated action (always
>>>>>>>>>> > prompts user) possible and actions are predefined at keycloak I
>>>>>>>>>> see no
>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>> > wrote:
>>>>>>>>>> > >
>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>> prompt the user
>>>>>>>>>> > to
>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>> authenticating, but
>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>> > >
>>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>>> email, etc.
>>>>>>>>>> > >
>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>> registered with the
>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>> themselves. As an
>>>>>>>>>> > > example it may not be required by all users to verify their
>>>>>>>>>> email, but
>>>>>>>>>> > only
>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>> > >
>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>> management
>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>> verifying the
>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>> > >
>>>>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>>>>> Initiated
>>>>>>>>>> > > Actions. An Application Initiated Action behind the scenes is
>>>>>>>>>> just a
>>>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>>>> depending on
>>>>>>>>>> > the
>>>>>>>>>> > > action may be optional for the user to complete (where the
>>>>>>>>>> user can
>>>>>>>>>> > select
>>>>>>>>>> > > cancel which would return the user back to the application).
>>>>>>>>>> > >
>>>>>>>>>> > > No Application Initiated Actions should perform any updates
>>>>>>>>>> to the users
>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>> application
>>>>>>>>>> > > initiated action that is used to link an existing account to
>>>>>>>>>> a social
>>>>>>>>>> > > provider should ask the user first if they want to link to
>>>>>>>>>> the provider.
>>>>>>>>>> > >
>>>>>>>>>> > > To make it easy for applications to integrate these I would
>>>>>>>>>> like to
>>>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>>>> authenticate
>>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>>> would redirect
>>>>>>>>>> > to
>>>>>>>>>> > > the authentication endpoint and add kc_action=<action alias>
>>>>>>>>>> query
>>>>>>>>>> > > parameter.
>>>>>>>>>> > >
>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>> Application Initiated
>>>>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>>>>> mechanism in
>>>>>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>>>>>> initiate an
>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>> applications.
>>>>>>>>>> > >
>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>> Application
>>>>>>>>>> > > Initiated Action to require the user to re-authenticate prior
>>>>>>>>>> to
>>>>>>>>>> > performing
>>>>>>>>>> > > the action. For example update password should require the
>>>>>>>>>> user to enter
>>>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>>>> simply sends
>>>>>>>>>> > an
>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>> > > _______________________________________________
>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>> > > https://lists.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 takashi.norimatsu.ws at hitachi.com  Thu Mar  7 21:21:42 2019
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Fri, 8 Mar 2019 02:21:42 +0000
Subject: [keycloak-dev] PKCE in keycloak-servlet-oauth-client does not work
Message-ID: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>

Hello,

I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange) support for keycloak and merged.
At that time, I had also implemented client side PKCE in servlet oauth client to demonstrate how PKCE works.

However, it seemed that I had pushed servlet oauth client codes that did not work instead of ones used in my local environment.
Therefore, client side PKCE in servlet oauth client does not work.

I've already known how to fix it, but it is difficult to write Arquillian integration tests.

I've searched existing Arquillian integration tests for servlet oauth client but not found.

Could anyone help me?

Best regards,
Takashi Norimatsu
Hitachi Ltd.,


From sthorger at redhat.com  Fri Mar  8 02:17:26 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Mar 2019 08:17:26 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
Message-ID: <CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>

On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Is it this stuff you're thinking about:
>>
>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>
>> From that it does a get including the ticket as a query parameter. I
>> don't like the idea of sending tickets as query params as they could be
>> logged. For the application initiated action it would have to be an ID
>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>> creating a ticket that can only be used to initiate an action.
>>
>
> Why you need to send the id token if the client already got an id token
> and, considering browser flow, there is a cookie that can be used by
> Keycloak to identify the client/user ?
>

Cookie doesn't authenticate the client, only the user.


>
>
>>
>> Perhaps what we could do is:
>>
>> 1. By default any application can initiate an action
>> 1.1. To initiate an action there's no need for a ticket of any sort, just
>> a regular oauth flow
>> 2. Later add support if demand to limit what applications can initiate
>> actions
>> 2.1 Same as before if the action being initiated is open for everyone
>> then no need for a ticket
>> 2.2 If the action being initiated is only permitted by some applications
>> we would need some form of authentication.
>>
>> For 2.2 I have 3 suggestions in mind:
>>
>> a. Just include id_token as a ticket query param like  UMA claim redirect
>> does
>> b. Add support to obtain an initiate action ticket from a endpoint using
>> an id token as bearer token
>> c. Add a note into client session with a initiate action ticket for
>> clients that can initiate actions and map this into the id token.
>>
>
> Not sure ...
>
> If you think about it, the part interested in obtaining the claims after
> an action is completed is not the client but the audience of the token, the
> resource server. In this case, the UMA approach seems more appropriate
> because the resource server is in control about what actions the client
> should initiate in order to fulfill the constraints imposed by the resource
> server to access its protected resources. Where these constraints could be
> a DOB in the token or a higher security level.
>
> The app initiating actions in the server is not the goal, but the tool to
> obtain additional claims from the server ...
>
> However, for some applications acting as both client and resource server
> (e.g.: a monolithic jee) can avoid all the ticket dance and just redirect
> the user to the server as you pointed out in 1.
>

Perhaps there's a case for that, but that would be claims gathering, not
application initiated actions.

Application initiated actions are more a tool for folks to add actions for
the user account into their own GUIs, and as such should be a simple
protocol. OAuth incremental scopes for example doesn't have any flows
between app and service, but rather just allows the app to get the scopes
it out of bounds knows it needs for specific actions.


>
>
>>
>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Why do you think authentication/authorization is required? The user
>>>>>>> will be prompted before making an action and it's an action they do against
>>>>>>> RH-SSO and not automatically visible/exposed to the client.
>>>>>>>
>>>>>>
>>>>>> The client is making the request and even though the user is at the
>>>>>> Keycloak server to perform the action, admins may want to restrict which
>>>>>> clients are allowed to perform such actions. That is what I mean by some
>>>>>> level of authorization.
>>>>>>
>>>>>> You could even consider not authenticating the client at all, but
>>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>>> actions on the server.
>>>>>>
>>>>>
>>>>> I can't see how enforcing which clients is allowed to initiate actions
>>>>> will work without authenticating the client.
>>>>>
>>>>
>>>> Maybe the word authenticate seems too much to what we are discussing.
>>>> This is more a validation of the client making the request. Considering
>>>> that, I'm saying that you could just rely on client_id and redirect uris
>>>> (the client is already authenticated and if doing browser authentication
>>>> the cookie is already present) and possibly add some level of authorization
>>>> to enforce which clients can perform actions (instead of just relying on
>>>> the authenticated session). Redirect uris are really important because you
>>>> want to make sure the redirect uri is valid before redirecting the user.
>>>>
>>>
>>> The plan is to use the auth endpoint, so client_id and redirect_uris are
>>> already being checked. It's just a standard OAuth flow.
>>>
>>> IMO that's fine as long as there's no need to limit what clients can
>>> initiate actions. If that's needed then we need something more complicated
>>> that properly authenticates the client, as anyone could just use the
>>> client_id and redirect_uri from a different application to get the action
>>> initiated (although wouldn't then have the user redirected back to the app
>>> of course).
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One way is to follow authorization code constraints like checking
>>>>>>>> the client_id and redirect_uri (assuming the user will be redirected back
>>>>>>>> after the action completes). But still, we could also add some level
>>>>>>>> authorization.
>>>>>>>>
>>>>>>>
>>>>>>> authorization code constraints doesn't work as anyone can just use
>>>>>>> the client_id and redirect_uri from a different client.
>>>>>>>
>>>>>>
>>>>>> I may be missing the whole flow. I would ask then what happens after
>>>>>> the user performs an action. Is he/her redirected back to the client ? If
>>>>>> so, client_id + redirect_uri do work to make sure that the client is known
>>>>>> and that the user will be redirected back to a valid URI.
>>>>>>
>>>>>
>>>>> It's just a standard OAuth flow, so app would get new tokens. Say the
>>>>> user hasn't entered a DOB in the profile and the client wants that, then
>>>>> they can request the user to enter a DOB, which would then result in the
>>>>> DOB being available in the token.
>>>>>
>>>>
>>>> This flow seems very closely related with the Claims Gathering Flow
>>>> from UMA specs. We could probably review what is there and see if it can
>>>> help to solve this problem of app initiated actions.
>>>>
>>>
>>> Go for it ;)
>>>
>>>
>>>>
>>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Only viable option I can think of is to add an endpoint where the
>>>>>>> application can request a token to initate an action. So flow would be:
>>>>>>>
>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>>>> token in header to a new endpoint. This would return a single use token.
>>>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>
>>>>>>> In the JS adapter we can add a action(actionId) function that would
>>>>>>> get the action token before redirecting the user.
>>>>>>>
>>>>>>> Not sure what you mean about level authorization.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> The issue is more around how to authenticate clients and also the
>>>>>>>>> fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>> the OIDC flows.
>>>>>>>>>
>>>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>>>
>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>> in regards to authentication.
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>
>>>>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>>>>> wanting to
>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>> securing it and
>>>>>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>>>>>> welcome
>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Since there is no "silent" application initiated action (always
>>>>>>>>>>> > prompts user) possible and actions are predefined at keycloak
>>>>>>>>>>> I see no
>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> > >
>>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>>> prompt the user
>>>>>>>>>>> > to
>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>> authenticating, but
>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>> > >
>>>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>>>> email, etc.
>>>>>>>>>>> > >
>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>> registered with the
>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>> themselves. As an
>>>>>>>>>>> > > example it may not be required by all users to verify their
>>>>>>>>>>> email, but
>>>>>>>>>>> > only
>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>> > >
>>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>>> management
>>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>>> verifying the
>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>> > >
>>>>>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>>>>>> Initiated
>>>>>>>>>>> > > Actions. An Application Initiated Action behind the scenes
>>>>>>>>>>> is just a
>>>>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>>>>> depending on
>>>>>>>>>>> > the
>>>>>>>>>>> > > action may be optional for the user to complete (where the
>>>>>>>>>>> user can
>>>>>>>>>>> > select
>>>>>>>>>>> > > cancel which would return the user back to the application).
>>>>>>>>>>> > >
>>>>>>>>>>> > > No Application Initiated Actions should perform any updates
>>>>>>>>>>> to the users
>>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>>> application
>>>>>>>>>>> > > initiated action that is used to link an existing account to
>>>>>>>>>>> a social
>>>>>>>>>>> > > provider should ask the user first if they want to link to
>>>>>>>>>>> the provider.
>>>>>>>>>>> > >
>>>>>>>>>>> > > To make it easy for applications to integrate these I would
>>>>>>>>>>> like to
>>>>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>>>>> authenticate
>>>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>>>> would redirect
>>>>>>>>>>> > to
>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action alias>
>>>>>>>>>>> query
>>>>>>>>>>> > > parameter.
>>>>>>>>>>> > >
>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>> Application Initiated
>>>>>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>>>>>> mechanism in
>>>>>>>>>>> > > place to restrict what clients/applications are permitted to
>>>>>>>>>>> initiate an
>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>> applications.
>>>>>>>>>>> > >
>>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>>> Application
>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>> prior to
>>>>>>>>>>> > performing
>>>>>>>>>>> > > the action. For example update password should require the
>>>>>>>>>>> user to enter
>>>>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>>>>> simply sends
>>>>>>>>>>> > an
>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>> >
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>
>>>>>>>>>>

From sthorger at redhat.com  Fri Mar  8 02:26:05 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Mar 2019 08:26:05 +0100
Subject: [keycloak-dev] PKCE in keycloak-servlet-oauth-client does not
	work
In-Reply-To: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
References: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAdViNer97Yy0NXmn=vf+goSj36MZUjN9A6Ac+YPPkKbdQ@mail.gmail.com>

I'm not sure what use-cases servlet-oauth-client aims to cover and I'm not
sure why we have it in the first place. It's not documented nor is it well
tested as far as I can tell.

On Fri, 8 Mar 2019 at 03:26, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello,
>
> I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange)
> support for keycloak and merged.
> At that time, I had also implemented client side PKCE in servlet oauth
> client to demonstrate how PKCE works.
>
> However, it seemed that I had pushed servlet oauth client codes that did
> not work instead of ones used in my local environment.
> Therefore, client side PKCE in servlet oauth client does not work.
>
> I've already known how to fix it, but it is difficult to write Arquillian
> integration tests.
>
> I've searched existing Arquillian integration tests for servlet oauth
> client but not found.
>
> Could anyone help me?
>
> Best regards,
> Takashi Norimatsu
> Hitachi Ltd.,
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From alistair.doswald at elca.ch  Fri Mar  8 05:09:57 2019
From: alistair.doswald at elca.ch (Doswald Alistair)
Date: Fri, 8 Mar 2019 10:09:57 +0000
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
	implementing JIRAs
Message-ID: <24cbd52475494e4a95f9282a280d8fde@elca.ch>

Hello,


I've been following the thread about the implementation of WebAuthn in Keycloak, and saw that there are some related JIRAs in the following design document https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md.


Is anyone  already working on JIRAs https://issues.jboss.org/browse/KEYCLOAK-9693 and https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd factor authenticators? If not, with my colleagues we could implement them relatively quickly as we have use cases for these functionalities.


Best regards,


Alistair Doswald

From sthorger at redhat.com  Fri Mar  8 07:17:15 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Mar 2019 13:17:15 +0100
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
	implementing JIRAs
In-Reply-To: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
Message-ID: <CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>

No one is working on the admin part at the moment, so contributions here
would be very welcome. It's not a straightforward task though and would
need a fair bit of design/prototyping/discussions to get this right.

On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch>
wrote:

> Hello,
>
>
> I've been following the thread about the implementation of WebAuthn in
> Keycloak, and saw that there are some related JIRAs in the following design
> document
> https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md
> .
>
>
> Is anyone  already working on JIRAs
> https://issues.jboss.org/browse/KEYCLOAK-9693 and
> https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd
> factor authenticators? If not, with my colleagues we could implement them
> relatively quickly as we have use cases for these functionalities.
>
>
> Best regards,
>
>
> Alistair Doswald
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From niko at n-k.de  Fri Mar  8 07:19:26 2019
From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=)
Date: Fri, 8 Mar 2019 13:19:26 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for implicit
	flow
Message-ID: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>

Hi team,

I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
Anybody interested in discussing?

- Niko



From tkyjovsk at redhat.com  Fri Mar  8 14:45:11 2019
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Fri, 8 Mar 2019 14:45:11 -0500 (EST)
Subject: [keycloak-dev] Microservice-oriented Integration Testing
In-Reply-To: <1862713637.7709667.1552064701102.JavaMail.zimbra@redhat.com>
Message-ID: <1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>

I have some ideas about a possible future direction of the testsuite. I wanted to kick off a discussion around this topic and see what others think.

In context of the microservice paradigm our current approach to integration testing seems a bit monolithic.
We run the whole testsuite on a single "all-in-one" host, while a typical SSO use case always involves interaction of at least 3 separate entities spread across different hosts, talking to each other via network.

1) SSO server
  + server-side integrations: JPA/cache server, LDAP server, external IDP, etc.
  + possible clustering/scaling/failover/upgrade scenarios
2) SSO client (secured service)
  + multiple different services, different runtimes
  + possibly clustered
3) SSO user (delegated by user agent / browser)

The all-in-one approach still works, and it's perhaps better for local development-testing loop, but it's just a bit weird in proper integration testing that for example browser (in UI compatibility tests) runs on the same machine with the server and all the other services. I've been wondering if it's worth pushing for a more microservice-oriented approach with proper service decomposition.

More detailed service decomposition here, feel free to add comments on it: [1].

Advatanges:
- more realistic setup
- issues which don't appear when testing on a single host can be discovered
- different setups on server / client / user side can be provisioned and combined independently
- the test machine itself could be reduced to git + one JDK + Maven + cloud client tools (e.g. docker, novaclient, etc.)
- ... anything else?

Disadvantages:
- additional work, unclear how much
- increased complexity, a different set of challenges related to provisioning (but with local docker not that much)
- needs preparation/configuration of VM images for all tested services
- not sure right now how we would handle some corner cases like service restarts/reconfigs which are needed for some tests
- some tests might have to be rewritten/adapted to the non-localhost environment
- ... anything else?

Options:
- docker / podman
- openshift / kubernetes
- openstack, aws or similar cloud
- a combination of the above?

In general the process would look like this: build project --> build distro zips --> build VM images --> run tests while the testsuite itself would be able to provision and teardown the tested system (or its individual components) from the pre-built images. We already use something like this in the performance testsuite (docker + docker compose). Maybe it could be generalized to the whole testsuite.

Since the integration testsuite already uses Arquillian I think that the Arquillian Cube extension [2] would be an obvious candidate because it supports both Docker (incl. the Compose orchestration format) and Kubernetes/Openshift cluster (need to investigate extent of support). While also keeping the default JVM-embedded test mode for development.

For additional separation, we could also start using the remote Webdriver mode instead being tied to the browser installed locally on the test machine. Arquillian is able send commands to a remote Selenium Grid [3] which has a bunch of independent browser nodes and relay the commands. The grid is provisioned separately, and there is already some automation for it in docker [4]. (I already did a quick test a while ago. There were some minor issues but with some effort I think it could work.)

Some ideas to think about. Let me  know what you think, or if you have some other ideas/solutions related to this topic.


Tomas

[1] https://docs.google.com/spreadsheets/d/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JEgcmaR3AiTQ/
[2] http://arquillian.org/arquillian-cube/
[3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
[4] https://github.com/SeleniumHQ/docker-selenium

From vmuzikar at redhat.com  Fri Mar  8 15:38:41 2019
From: vmuzikar at redhat.com (=?UTF-8?B?VsOhY2xhdiBNdXppa8OhxZk=?=)
Date: Fri, 8 Mar 2019 21:38:41 +0100
Subject: [keycloak-dev] Microservice-oriented Integration Testing
In-Reply-To: <1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
References: <1862713637.7709667.1552064701102.JavaMail.zimbra@redhat.com>
	<1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
Message-ID: <CAMQSZyiv8fLeqXOKNp+bTWT3EjGv+Sg1bV-R=zd9ink-r3uYiQ@mail.gmail.com>

I quite like the idea of running those three entities separately,
especially in context of UI tests with desktop browsers (mobile browsers
are run in VMs in any case). However, I can see two problems with that.

1) We'd need to maintain both the current all-in-one approach and the
decoupled approach. Those two are quite different and it won't work "just
like that" over time - maintenance will be required. Do we have capacity
for this?

2) In order to make sense (as real environment as possible), the images
would need to be based on a fully-fledged OS (whole RHEL/Windows Server
distribution) - not just some bare minimum like Alpine. We'd need to either:
2.1) Use docker, i.e. basically a nested virtualization (we've got a
provisioned VM where the tests are run - same like now - and this VM would
host several more VMs with server/service/client). I'm afraid this could
bring potential problems (there's a difference in virtualizing some small
service in Docker and e.g. Windows Server in Docker) and a significant
overhead as well.
2.2) Use openstack/shift. This would mean running 3 large VMs for each part
of testsuite that's ran in parallel (in contrast to 1 like we have now). Do
we have resources for something like this? As an alternative, we could run
less tests in parallel, but I don't think this is something we want - to
run tests much more slower.

Regarding the Selenium Grid. I've researched it a bit in the past, and if I
understand it correctly, it's not usable for us. It's focused on parallel
test execution, i.e. running multiple tests in multiple browsers against 1
source (auth/app server). We need each browser to have a separate server
since the UI tests are changing it's configuration etc. Selenium Grid would
be good for testing some read-only app where concurrency is not a problem.
Not mentioning the fact that we already run UI tests in parallel (each
browser independently from others).

Remote Webdriver wouldn't be a problem. In fact, we are already using it!
FF/Chrome/IE drivers are technically remote drivers - it's just using
localhost. It might not seem so because the browser's execution is managed
by Arquillian Drone so everything seems seamless. But Drone doesn't need to
be the one who's executing the browser - it can be something completely
different on a different machine. And it wouldn't even require much changes
to the testsuite.

V.

On Fri, Mar 8, 2019 at 8:47 PM Tomas Kyjovsky <tkyjovsk at redhat.com> wrote:

> I have some ideas about a possible future direction of the testsuite. I
> wanted to kick off a discussion around this topic and see what others think.
>
> In context of the microservice paradigm our current approach to
> integration testing seems a bit monolithic.
> We run the whole testsuite on a single "all-in-one" host, while a typical
> SSO use case always involves interaction of at least 3 separate entities
> spread across different hosts, talking to each other via network.
>
> 1) SSO server
>   + server-side integrations: JPA/cache server, LDAP server, external IDP,
> etc.
>   + possible clustering/scaling/failover/upgrade scenarios
> 2) SSO client (secured service)
>   + multiple different services, different runtimes
>   + possibly clustered
> 3) SSO user (delegated by user agent / browser)
>
> The all-in-one approach still works, and it's perhaps better for local
> development-testing loop, but it's just a bit weird in proper integration
> testing that for example browser (in UI compatibility tests) runs on the
> same machine with the server and all the other services. I've been
> wondering if it's worth pushing for a more microservice-oriented approach
> with proper service decomposition.
>
> More detailed service decomposition here, feel free to add comments on it:
> [1].
>
> Advatanges:
> - more realistic setup
> - issues which don't appear when testing on a single host can be discovered
> - different setups on server / client / user side can be provisioned and
> combined independently
> - the test machine itself could be reduced to git + one JDK + Maven +
> cloud client tools (e.g. docker, novaclient, etc.)
> - ... anything else?
>
> Disadvantages:
> - additional work, unclear how much
> - increased complexity, a different set of challenges related to
> provisioning (but with local docker not that much)
> - needs preparation/configuration of VM images for all tested services
> - not sure right now how we would handle some corner cases like service
> restarts/reconfigs which are needed for some tests
> - some tests might have to be rewritten/adapted to the non-localhost
> environment
> - ... anything else?
>
> Options:
> - docker / podman
> - openshift / kubernetes
> - openstack, aws or similar cloud
> - a combination of the above?
>
> In general the process would look like this: build project --> build
> distro zips --> build VM images --> run tests while the testsuite itself
> would be able to provision and teardown the tested system (or its
> individual components) from the pre-built images. We already use something
> like this in the performance testsuite (docker + docker compose). Maybe it
> could be generalized to the whole testsuite.
>
> Since the integration testsuite already uses Arquillian I think that the
> Arquillian Cube extension [2] would be an obvious candidate because it
> supports both Docker (incl. the Compose orchestration format) and
> Kubernetes/Openshift cluster (need to investigate extent of support). While
> also keeping the default JVM-embedded test mode for development.
>
> For additional separation, we could also start using the remote Webdriver
> mode instead being tied to the browser installed locally on the test
> machine. Arquillian is able send commands to a remote Selenium Grid [3]
> which has a bunch of independent browser nodes and relay the commands. The
> grid is provisioned separately, and there is already some automation for it
> in docker [4]. (I already did a quick test a while ago. There were some
> minor issues but with some effort I think it could work.)
>
> Some ideas to think about. Let me  know what you think, or if you have
> some other ideas/solutions related to this topic.
>
>
> Tomas
>
> [1]
> https://docs.google.com/spreadsheets/d/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JEgcmaR3AiTQ/
> [2] http://arquillian.org/arquillian-cube/
> [3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
> [4] https://github.com/SeleniumHQ/docker-selenium
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
V?clav Muzik??
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

From tkyjovsk at redhat.com  Fri Mar  8 17:59:05 2019
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Fri, 8 Mar 2019 17:59:05 -0500 (EST)
Subject: [keycloak-dev] Provisioning of Keycloak deployments
In-Reply-To: <736503484.7708504.1552064514435.JavaMail.zimbra@redhat.com>
Message-ID: <1269049447.7745451.1552085945195.JavaMail.zimbra@redhat.com>

Looking at the feedback in the questionare, there are several requests to make provisioning and configuration of KC deployments easier.

I was also thinking about this in relation to our testsuite for a while, and whether there should be a separate module for this. Either inside the testsuite module, or possibly even in the projecr root - in case we want it to be usable both by the testsuite (via API) and manually, by people who want to deploy Keycloak and other interacting sevices somewhere in their cloud or kubernetes/openshift cluster.

Another option would be to create an entirely separate project (akin to jboss-dockerfiles/keycloak [1] or the Kubernetes Helm project [2]) which could even support multiple versions of Keycloak and other components. Perhaps some install/upgrade wizzards and examples could be put there. Not sure how an external project would be usable with the testsuite though. The question is to what extent these two use cases are even compatible (devops/maintenance vs extensive integration testing). Benefit of combining both use cases would be reusing common stuff (DRY).

In the testsuite we currently use 2 different solutions:

1) Integration testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then manages lifecycle of all components through Arquillian. Additionally there are testsuite-specific server extensions and custom test apps.

2) Performance testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then uses Docker Compose to build and orchestrate the services. The tests then run against a "remote" provisioned system.
There is also a PR from Radim Vansa who created a provisioning solution for OpenShift a while ago, which I have yet to review and merge.
And we need to add some bare-metal provisioning option for testing in bare-metal labs (probably ansible).

I think all of these different solutions could be put under one roof.

Maybe something like this:

keycloak/
  ...
  core/
  adapters/
  model/
  examples/
  ...
  distribution/
  provisioning/
    provisioning-api/
    provisioner-local/
    provisioner-docker/
    provisioner-openshift/
    provisioner-ansible/
    ...
  testsuite/
    integration/
    performance/

Or like this, if just inside the testsuite:

keycloak/
  ...
  testsuite/
    provisioning/
    integration/
    performance/


The provisioning API would have a simple interface:

  interface Provisioner {
    List<String> getConfiguredServices();
    void buildService(String service);
    void startService(String service);
    void stopService(String service);
  }

Particular provisioner module would the look something like this:

provisioner-X/
  src/main/
    java/.../ProvisionerX.java   (wrapper for external provisioning tool or API)
    resources/...                (for exmple jboss-cli scripts, dockerfiles, ansible playbooks, etc.)
  pom.xml/<profiles>/
    server
    server-db-vendor-1
    server-db-vendor-2
    ...
    server-ldap-vendor-1
    server-ldap-vendor-2
    ...
    server-cache
    server-load-balancer
    client-set-1
    client-set-2
    client-set-3
    ...
    webdriver-vendor-1/
    webdriver-vendor-2/
    ...

The process would consist of:
1) Configuring required provisioner modules:
  - user provides connection parameters and credentials if needed (kubernetes/openshift, ssh keys for anisble, etc.)
  - user provides configuration parameters for services
2) Building required provisioner modules:
  - building provisioning module will prepare all local artifacts which will be needed for running methods of the Provisioner interface
  - after module is built the provisioner implementation/wrapper will be runnable directly with Java or indirectly from script (this would be useful the dev-ops scenario)
  - also the external provisioning tool (such as docker-compose or ansible) will be runnable directly at this point
3) Running the testsuite. The testsuite delegates to the API to spin up or tear down the services as needed.

The integration testsuite would default to the `provisioner-local` module which would just contain stuff which is now located in: testsuite/integration-arquillian/servers.
But it could be instructed to use a different provisioning module(s).

It would be nice if individual services or sets of services could be combined across different provisioners, and if this would also allow for integration of externally provided services such as existing DB servers.

That's the general idea. I've brought this up once before but it was never a priority. Maybe it's time to consider it again and let everyone chip in with their ideas.
I think this consolidation would be useful at least within the testsuite. It is also kind of related to the microservice-oriented testing approach which I mentioned in my previous post.


Regards,
Tomas


[1] https://github.com/jboss-dockerfiles/keycloak
[2] https://github.com/helm/charts/tree/master/stable/keycloak

From niko at n-k.de  Sat Mar  9 04:39:31 2019
From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=)
Date: Sat, 9 Mar 2019 10:39:31 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
 implicit flow
In-Reply-To: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
Message-ID: <031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>

I've just created a pull request for this issue, including docs, but still without tests.
https://github.com/keycloak/keycloak/pull/5932

As the tests are quite complex to run, and I didn't find any information about how to run/execute just the JavascriptAdapterTest.java class without running the whole testsuite over and over again, I'd appreciate any help/hint, of how to run this test only.

Thanks,
- Niko



> Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de>:
> 
> Hi team,
> 
> I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
> I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
> Anybody interested in discussing?
> 
> - Niko
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From jdennis at redhat.com  Sat Mar  9 09:07:21 2019
From: jdennis at redhat.com (John Dennis)
Date: Sat, 9 Mar 2019 09:07:21 -0500
Subject: [keycloak-dev] Provisioning of Keycloak deployments
In-Reply-To: <1269049447.7745451.1552085945195.JavaMail.zimbra@redhat.com>
References: <1269049447.7745451.1552085945195.JavaMail.zimbra@redhat.com>
Message-ID: <763cb40f-3320-7825-9d40-d50c0b9a95db@redhat.com>

On 3/8/19 5:59 PM, Tomas Kyjovsky wrote:
> Looking at the feedback in the questionare, there are several 
> requests to make provisioning and configuration of KC deployments 
> easier.

> I was also thinking about this in relation to our testsuite for a
 > while ...

FYI we in the middle of developing Ansible tools to deploy and
configure Keycloak. This effort is aimed at testing single sign-on
federation in OpenStack in a CI environment. There is an opportunity
here for collaboration.

Nathan Kinder recently wrote this Ansible role to deploy the Keycloak 
server, I expect it will be submitted to upstream Ansible once it has a 
bit more soak time.

https://github.com/nkinder/ansible-keycloak

I'm in the process of using this in conjunction with the existing 
ansible keycloak_client and some new Ansible roles to establish 
federation in OpenStack. While it is true our work targets OpenStack 
there is no reason why the components cannot form the basis of a toolbox 
for a host of other deployment and testng needs.
-- 
John Dennis

From diegoliber at gmail.com  Sat Mar  9 22:03:52 2019
From: diegoliber at gmail.com (Diego Liberalquino)
Date: Sun, 10 Mar 2019 00:03:52 -0300
Subject: [keycloak-dev] Implementation of Front-Channel Logout for OpenID
	Connect clients
Message-ID: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>

Hello,

A thing that bothers me on Keycloak is the lack of implementation of
Front-Channel Logout for OpenID Clients. Is there any technical reason for
this or is just awaiting a community contribution? I mean, the spec is
supported for SAML clients, and it also works for external OIDC providers.

Best regards,
Diego Liberalquino

From gvincent at redhat.com  Mon Mar 11 04:27:25 2019
From: gvincent at redhat.com (Guillaume Vincent)
Date: Mon, 11 Mar 2019 09:27:25 +0100
Subject: [keycloak-dev] Microservice-oriented Integration Testing
In-Reply-To: <CAMQSZyiv8fLeqXOKNp+bTWT3EjGv+Sg1bV-R=zd9ink-r3uYiQ@mail.gmail.com>
References: <1862713637.7709667.1552064701102.JavaMail.zimbra@redhat.com>
	<1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
	<CAMQSZyiv8fLeqXOKNp+bTWT3EjGv+Sg1bV-R=zd9ink-r3uYiQ@mail.gmail.com>
Message-ID: <CAJbDe2vhAUGqzYbGq2T0+f8joY+NPAzwe_rgtAvVeEknKVjbvg@mail.gmail.com>

Hello,

TLDR: I think end to end testing using selenium and web driver to test in
different browser is a waste of time.

fyi: Facebook run unit tests for thousands of test files and tens of
thousands of modules directly in node. They don?t run those tests in
different browsers:

> After living with this problem for a while we discovered that Node tests
cover our internal logic really well, and browser tests, even if we had
them, don?t give us enough confidence. Many browser issues and regressions
that we have had are unobservable from the code, and need actual human
interaction. They are also very tedious to write and understand.
> I think at this point we won?t be investing into running our unit tests
in the browser. The combination of Node unit tests and manual DOM tests
seems to be working well, and further work might include making DOM
fixtures easier to access. Dan Abramov
<https://github.com/facebook/react/issues/5703#issuecomment-314770489>

I don't want to transform this thread in ui integration testing debate.
Integration tests are always difficult to understand and write.
You probably need to verify that those tests give you enough confidence,
and catch bugs present on one browser specifically.


> We need each browser to have a separate server since the UI tests are
changing it's configuration etc. Selenium Grid would be good for testing
some read-only app where concurrency is not a problem.

> if you have some other ideas/solutions related to this topic.

An idea is to make integration tests idempotent, to make tests parallels
and speed up test suite.

Cheers


On Fri, Mar 8, 2019 at 9:47 PM V?clav Muzik?? <vmuzikar at redhat.com> wrote:

> I quite like the idea of running those three entities separately,
> especially in context of UI tests with desktop browsers (mobile browsers
> are run in VMs in any case). However, I can see two problems with that.
>
> 1) We'd need to maintain both the current all-in-one approach and the
> decoupled approach. Those two are quite different and it won't work "just
> like that" over time - maintenance will be required. Do we have capacity
> for this?
>
> 2) In order to make sense (as real environment as possible), the images
> would need to be based on a fully-fledged OS (whole RHEL/Windows Server
> distribution) - not just some bare minimum like Alpine. We'd need to
> either:
> 2.1) Use docker, i.e. basically a nested virtualization (we've got a
> provisioned VM where the tests are run - same like now - and this VM would
> host several more VMs with server/service/client). I'm afraid this could
> bring potential problems (there's a difference in virtualizing some small
> service in Docker and e.g. Windows Server in Docker) and a significant
> overhead as well.
> 2.2) Use openstack/shift. This would mean running 3 large VMs for each part
> of testsuite that's ran in parallel (in contrast to 1 like we have now). Do
> we have resources for something like this? As an alternative, we could run
> less tests in parallel, but I don't think this is something we want - to
> run tests much more slower.
>
> Regarding the Selenium Grid. I've researched it a bit in the past, and if I
> understand it correctly, it's not usable for us. It's focused on parallel
> test execution, i.e. running multiple tests in multiple browsers against 1
> source (auth/app server). We need each browser to have a separate server
> since the UI tests are changing it's configuration etc. Selenium Grid would
> be good for testing some read-only app where concurrency is not a problem.
> Not mentioning the fact that we already run UI tests in parallel (each
> browser independently from others).
>
> Remote Webdriver wouldn't be a problem. In fact, we are already using it!
> FF/Chrome/IE drivers are technically remote drivers - it's just using
> localhost. It might not seem so because the browser's execution is managed
> by Arquillian Drone so everything seems seamless. But Drone doesn't need to
> be the one who's executing the browser - it can be something completely
> different on a different machine. And it wouldn't even require much changes
> to the testsuite.
>
> V.
>
> On Fri, Mar 8, 2019 at 8:47 PM Tomas Kyjovsky <tkyjovsk at redhat.com> wrote:
>
> > I have some ideas about a possible future direction of the testsuite. I
> > wanted to kick off a discussion around this topic and see what others
> think.
> >
> > In context of the microservice paradigm our current approach to
> > integration testing seems a bit monolithic.
> > We run the whole testsuite on a single "all-in-one" host, while a typical
> > SSO use case always involves interaction of at least 3 separate entities
> > spread across different hosts, talking to each other via network.
> >
> > 1) SSO server
> >   + server-side integrations: JPA/cache server, LDAP server, external
> IDP,
> > etc.
> >   + possible clustering/scaling/failover/upgrade scenarios
> > 2) SSO client (secured service)
> >   + multiple different services, different runtimes
> >   + possibly clustered
> > 3) SSO user (delegated by user agent / browser)
> >
> > The all-in-one approach still works, and it's perhaps better for local
> > development-testing loop, but it's just a bit weird in proper integration
> > testing that for example browser (in UI compatibility tests) runs on the
> > same machine with the server and all the other services. I've been
> > wondering if it's worth pushing for a more microservice-oriented approach
> > with proper service decomposition.
> >
> > More detailed service decomposition here, feel free to add comments on
> it:
> > [1].
> >
> > Advatanges:
> > - more realistic setup
> > - issues which don't appear when testing on a single host can be
> discovered
> > - different setups on server / client / user side can be provisioned and
> > combined independently
> > - the test machine itself could be reduced to git + one JDK + Maven +
> > cloud client tools (e.g. docker, novaclient, etc.)
> > - ... anything else?
> >
> > Disadvantages:
> > - additional work, unclear how much
> > - increased complexity, a different set of challenges related to
> > provisioning (but with local docker not that much)
> > - needs preparation/configuration of VM images for all tested services
> > - not sure right now how we would handle some corner cases like service
> > restarts/reconfigs which are needed for some tests
> > - some tests might have to be rewritten/adapted to the non-localhost
> > environment
> > - ... anything else?
> >
> > Options:
> > - docker / podman
> > - openshift / kubernetes
> > - openstack, aws or similar cloud
> > - a combination of the above?
> >
> > In general the process would look like this: build project --> build
> > distro zips --> build VM images --> run tests while the testsuite itself
> > would be able to provision and teardown the tested system (or its
> > individual components) from the pre-built images. We already use
> something
> > like this in the performance testsuite (docker + docker compose). Maybe
> it
> > could be generalized to the whole testsuite.
> >
> > Since the integration testsuite already uses Arquillian I think that the
> > Arquillian Cube extension [2] would be an obvious candidate because it
> > supports both Docker (incl. the Compose orchestration format) and
> > Kubernetes/Openshift cluster (need to investigate extent of support).
> While
> > also keeping the default JVM-embedded test mode for development.
> >
> > For additional separation, we could also start using the remote Webdriver
> > mode instead being tied to the browser installed locally on the test
> > machine. Arquillian is able send commands to a remote Selenium Grid [3]
> > which has a bunch of independent browser nodes and relay the commands.
> The
> > grid is provisioned separately, and there is already some automation for
> it
> > in docker [4]. (I already did a quick test a while ago. There were some
> > minor issues but with some effort I think it could work.)
> >
> > Some ideas to think about. Let me  know what you think, or if you have
> > some other ideas/solutions related to this topic.
> >
> >
> > Tomas
> >
> > [1]
> >
> https://docs.google.com/spreadsheets/d/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JEgcmaR3AiTQ/
> > [2] http://arquillian.org/arquillian-cube/
> > [3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
> > [4] https://github.com/SeleniumHQ/docker-selenium
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>
> --
> V?clav Muzik??
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Guillaume Vincent
Senior Software Engineer

From sthorger at redhat.com  Mon Mar 11 04:39:37 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Mar 2019 09:39:37 +0100
Subject: [keycloak-dev] Microservice-oriented Integration Testing
In-Reply-To: <1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
References: <1862713637.7709667.1552064701102.JavaMail.zimbra@redhat.com>
	<1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAeptqcohT24vzcKT9e0+be5Tf5uDb1T+1eTJ+1i-JRmCw@mail.gmail.com>

In general it's a good idea and it can probably be done in stages rather
than as one big task.

Could be something like:

1. Run browser on a separate node. This could allow testing multiple
browsers concurrently with the same Keycloak server. Perhaps we could
create separate realms for each browser in order to allow them to run
concurrently.
2. Adapter tests. These should just provision a Keycloak server somehow in
a similar fashion to how we consume a DB from the server tests as we are
testing the adapter not the server here. Running two side-by-side in
Arquillian doesn't make all that much sense.
3. Allow tests to run separately to server. This will be required to allow
using the testsuite on Keycloak running on Docker or OpenShift.

On Fri, 8 Mar 2019 at 20:47, Tomas Kyjovsky <tkyjovsk at redhat.com> wrote:

> I have some ideas about a possible future direction of the testsuite. I
> wanted to kick off a discussion around this topic and see what others think.
>
> In context of the microservice paradigm our current approach to
> integration testing seems a bit monolithic.
> We run the whole testsuite on a single "all-in-one" host, while a typical
> SSO use case always involves interaction of at least 3 separate entities
> spread across different hosts, talking to each other via network.
>
> 1) SSO server
>   + server-side integrations: JPA/cache server, LDAP server, external IDP,
> etc.
>   + possible clustering/scaling/failover/upgrade scenarios
> 2) SSO client (secured service)
>   + multiple different services, different runtimes
>   + possibly clustered
> 3) SSO user (delegated by user agent / browser)
>
> The all-in-one approach still works, and it's perhaps better for local
> development-testing loop, but it's just a bit weird in proper integration
> testing that for example browser (in UI compatibility tests) runs on the
> same machine with the server and all the other services. I've been
> wondering if it's worth pushing for a more microservice-oriented approach
> with proper service decomposition.
>
> More detailed service decomposition here, feel free to add comments on it:
> [1].
>
> Advatanges:
> - more realistic setup
> - issues which don't appear when testing on a single host can be discovered
> - different setups on server / client / user side can be provisioned and
> combined independently
> - the test machine itself could be reduced to git + one JDK + Maven +
> cloud client tools (e.g. docker, novaclient, etc.)
> - ... anything else?
>
> Disadvantages:
> - additional work, unclear how much
> - increased complexity, a different set of challenges related to
> provisioning (but with local docker not that much)
> - needs preparation/configuration of VM images for all tested services
> - not sure right now how we would handle some corner cases like service
> restarts/reconfigs which are needed for some tests
> - some tests might have to be rewritten/adapted to the non-localhost
> environment
> - ... anything else?
>
> Options:
> - docker / podman
> - openshift / kubernetes
> - openstack, aws or similar cloud
> - a combination of the above?
>
> In general the process would look like this: build project --> build
> distro zips --> build VM images --> run tests while the testsuite itself
> would be able to provision and teardown the tested system (or its
> individual components) from the pre-built images. We already use something
> like this in the performance testsuite (docker + docker compose). Maybe it
> could be generalized to the whole testsuite.
>
> Since the integration testsuite already uses Arquillian I think that the
> Arquillian Cube extension [2] would be an obvious candidate because it
> supports both Docker (incl. the Compose orchestration format) and
> Kubernetes/Openshift cluster (need to investigate extent of support). While
> also keeping the default JVM-embedded test mode for development.
>
> For additional separation, we could also start using the remote Webdriver
> mode instead being tied to the browser installed locally on the test
> machine. Arquillian is able send commands to a remote Selenium Grid [3]
> which has a bunch of independent browser nodes and relay the commands. The
> grid is provisioned separately, and there is already some automation for it
> in docker [4]. (I already did a quick test a while ago. There were some
> minor issues but with some effort I think it could work.)
>
> Some ideas to think about. Let me  know what you think, or if you have
> some other ideas/solutions related to this topic.
>
>
> Tomas
>
> [1]
> https://docs.google.com/spreadsheets/d/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JEgcmaR3AiTQ/
> [2] http://arquillian.org/arquillian-cube/
> [3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
> [4] https://github.com/SeleniumHQ/docker-selenium
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mhajas at redhat.com  Mon Mar 11 04:45:34 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Mon, 11 Mar 2019 09:45:34 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
	implicit flow
In-Reply-To: <031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
	<031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
Message-ID: <CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>

Hello,

thank you very much for the contribution.

You can run JavascriptAdapterTest class using the following command
executed from keycloak directory:

mvn clean install -f testsuite/integration-arquillian/pom.xml
-Dtest=JavascriptAdapterTest

Best regards,
Michal

On Sat, Mar 9, 2019 at 10:41 AM Niko K?bler <niko at n-k.de> wrote:

> I've just created a pull request for this issue, including docs, but still
> without tests.
> https://github.com/keycloak/keycloak/pull/5932
>
> As the tests are quite complex to run, and I didn't find any information
> about how to run/execute just the JavascriptAdapterTest.java class without
> running the whole testsuite over and over again, I'd appreciate any
> help/hint, of how to run this test only.
>
> Thanks,
> - Niko
>
>
>
> > Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de>:
> >
> > Hi team,
> >
> > I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795
> as this is needed in one of my customers projects and it increases security
> in handling tokens in SPAs.
> > I've already an idea of how to implement it (and a very rough working
> draft), but would like to discuss this first with someone of you.
> > Anybody interested in discussing?
> >
> > - Niko
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.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 niko at n-k.de  Mon Mar 11 06:34:56 2019
From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=)
Date: Mon, 11 Mar 2019 11:34:56 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
 implicit flow
In-Reply-To: <CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
	<031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
	<CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>
Message-ID: <284703E1-812B-4497-9F9C-84D263445D9E@n-k.de>

Thanks Michal,

thanks for the help.
I struggled before with the notation from here https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-adapter-tests, as I needed to put the class name of the tests in quotes: -Dtest="org.keycloak.testsuite.adapter.**.*Test" - otherwise I got some shell errors.

I just pushed the test, build is running.
(It's like a nightmare to implement some tests, if you are not aware of all this stuff, as all your test classes are poorly (aka not-at-all) documented. If you want contributions from the community, you should change this!)
Hope to get it merged soon. :)

Regards,
- Niko

> Am 11.03.2019 um 09:45 schrieb Michal Hajas <mhajas at redhat.com>:
> 
> Hello,
> 
> thank you very much for the contribution. 
> 
> You can run JavascriptAdapterTest class using the following command executed from keycloak directory:
> 
> mvn clean install -f testsuite/integration-arquillian/pom.xml -Dtest=JavascriptAdapterTest
> 
> Best regards,
> Michal
> 
> On Sat, Mar 9, 2019 at 10:41 AM Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>> wrote:
> I've just created a pull request for this issue, including docs, but still without tests.
> https://github.com/keycloak/keycloak/pull/5932 <https://github.com/keycloak/keycloak/pull/5932>
> 
> As the tests are quite complex to run, and I didn't find any information about how to run/execute just the JavascriptAdapterTest.java class without running the whole testsuite over and over again, I'd appreciate any help/hint, of how to run this test only.
> 
> Thanks,
> - Niko
> 
> 
> 
> > Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>>:
> > 
> > Hi team,
> > 
> > I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 <https://issues.jboss.org/browse/KEYCLOAK-6795> as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
> > I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
> > Anybody interested in discussing?
> > 
> > - Niko
> > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

From h2-wada at nri.co.jp  Mon Mar 11 07:38:10 2019
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Mon, 11 Mar 2019 20:38:10 +0900
Subject: [keycloak-dev] keycloak-documentation translation into Japanese
Message-ID: <5C8648A2.6090505@nri.co.jp>

Hello,

Today, we completed translating all 8 documents for version 4.8.3.Final into Japanese!!
You can see them from the following site.

https://keycloak-documentation.openstandia.jp/4.8.3.Final


Best Regards,

-- 
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp



From sthorger at redhat.com  Mon Mar 11 07:58:53 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Mar 2019 12:58:53 +0100
Subject: [keycloak-dev] keycloak-documentation translation into Japanese
In-Reply-To: <5C8648A2.6090505@nri.co.jp>
References: <5C8648A2.6090505@nri.co.jp>
Message-ID: <CAJgngAdpQ_-hAHc32gr+oO2+qtPc-G5zOAxPHmJ-sZuGhtA7jQ@mail.gmail.com>

Nice :)

On Mon, 11 Mar 2019 at 12:42, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:

> Hello,
>
> Today, we completed translating all 8 documents for version 4.8.3.Final
> into Japanese!!
> You can see them from the following site.
>
> https://keycloak-documentation.openstandia.jp/4.8.3.Final
>
>
> Best Regards,
>
> --
> Hiroyuki Wada
> Nomura Research Institute, Ltd.
> h2-wada at nri.co.jp
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From maurodewit at gmail.com  Tue Mar 12 04:26:12 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Tue, 12 Mar 2019 09:26:12 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
Message-ID: <CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>

Hello,

I am sending this e-mail because I have some questions regarding the
enhancement request that enables configurable session limiting in Keycloak
as discussed here:
https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc Wijma
referred to in his comment as being available for this task is me btw :))

In the comments a solution is proposed that makes use of a custom
Authenticator that is dropped into the authentication flow where it can be
configured. While I can see the benefit of leveraging the existing
components as much as possible (including the configuration options in that
flow), I am wondering if this is the best solution. As far as I can tell,
this component is not performing any authentication at all. Moreover this
functionality operates 'above' the authentication mechanisms and should
apply to all of them.
So is an Authenticator really the desired place to implement this? Or is
this just the quickest route, while not being the most desirable option for
the long term? What would be an alternative approach be? That would place
this implementation and configuration in the existing Session configuration
code for instance.

I just now started investigating this task and looking into the options
that would meet our requirements. Hope to hear from you.

Regards

Mauro

>

From francesco.degrassi at optionfactory.net  Tue Mar 12 06:19:39 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Tue, 12 Mar 2019 11:19:39 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
	Identity Provider
Message-ID: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>

Hello,
we're testing Keycloak with Google as a social identity provider and using
the token exchange functionality to get access to the IDP access token.
I noticed that Google requires the access_type parameter to be set to
"offline" in the call to the authorization endpoint to release a refresh
token, but there is no easy way to do this in Keycloak; configuring a
generic OIDC identity provider allows me to configure access_type as a
forwarded parameter, but no such option exists using GoogleIdentityProvider.

I have a patch that (a) modifies GoogleIdentityProviderConfig and overrides
getForwardedParameters() to add "access_type" to the returned values.

Other options I considered include (b) changing the UI to allow to
configure the forwareded parameters for GoogleIdentityProvider (since it
extends OidcIdentityProvider) or (c) add a boolean configuration option to
GoogleIdentityProviderConfig to allow/disallow forwarding the parameter or
(d) add a boolean configuration option to GoogleIdentityProviderConfig to
set "access_type" to "offline" if checked.

Which would be the preferred route? Would a pull request be accepted?
Cheers.

*Francesco Degrassi*
Tech Lead
+39 329 4128 422 <+39+329+4128+422>
*OptionFactory <http://www.optionfactory.net/>*

From francesco.degrassi at optionfactory.net  Tue Mar 12 06:26:10 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Tue, 12 Mar 2019 11:26:10 +0100
Subject: [keycloak-dev] IDP Refresh token lost on first refresh during
 internal to external token exchange
Message-ID: <CAC-SaSxuoQhupWi+wKJVtUbZVTia3NLBb7CYNyYzgwKjFQzYKg@mail.gmail.com>

When performing an internal to external token exchange, if the requested
IDP access token is expired, Keycloak performs a token refresh using the
originally obtained access token.
After the operation is complete, the original token response is discarded
and the new one is saved; unless the new one includes a refresh token, the
refresh token is then lost and subsequent token exchanges requiring an IDP
token refresh will fail.

This happens regularly with Google as an IDP, since the token refresh
response does not include a refresh token, which is only provided in the
original authorization code exchange.

I have a patch to OidcIdentityProvider which ensures that the original
refresh token is saved if a new one has not been provided during the token
refresh operation. Should I proceed and provide a PR?

Cheers.

*Francesco Degrassi*
Tech Lead
+39 329 4128 422 <+39+329+4128+422>
*OptionFactory <http://www.optionfactory.net/>*

From mposolda at redhat.com  Tue Mar 12 07:19:21 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 12 Mar 2019 12:19:21 +0100
Subject: [keycloak-dev] Implementation of Front-Channel Logout for
 OpenID Connect clients
In-Reply-To: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
References: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
Message-ID: <4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>

Hi,

there is this JIRA opened already [1] . We have it planned, so we want 
to look at it, but lack of other things caused that this wasn't 
prioritized in last years... Do you want to contribute the feature?

BTV. There is this old discussion when we discuss the "iframes" to be 
used for frontchannel logout rather than redirect based approach [2]. 
You can see some more context by going through this old thread. I think 
that we already support iframe based frontchannel logout for SAML 
specification, or at least it is already available in Hynek's branch as 
mentioned in the comment of this JIRA [3]. So hopefully OIDC can re-use 
some parts of it.

Let us know if you're interested in contributing this.

[1] https://issues.jboss.org/browse/KEYCLOAK-2939
[2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.htm
[3] https://issues.jboss.org/browse/KEYCLOAK-5449

Marek

On 10/03/2019 04:03, Diego Liberalquino wrote:
> Hello,
>
> A thing that bothers me on Keycloak is the lack of implementation of
> Front-Channel Logout for OpenID Clients. Is there any technical reason for
> this or is just awaiting a community contribution? I mean, the spec is
> supported for SAML clients, and it also works for external OIDC providers.
>
> Best regards,
> Diego Liberalquino
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From thomas.darimont at googlemail.com  Tue Mar 12 07:36:12 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Mar 2019 12:36:12 +0100
Subject: [keycloak-dev] Implementation of Front-Channel Logout for
 OpenID Connect clients
In-Reply-To: <4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>
References: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
	<4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>
Message-ID: <CAK-7U1gbAv3Vag0soYiAtuPxw7Jnn43imvjFKBqOsSiHosrqdQ@mail.gmail.com>

Link to the discussion was broken:
[2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.html

Am Di., 12. M?rz 2019 um 12:30 Uhr schrieb Marek Posolda <
mposolda at redhat.com>:

> Hi,
>
> there is this JIRA opened already [1] . We have it planned, so we want
> to look at it, but lack of other things caused that this wasn't
> prioritized in last years... Do you want to contribute the feature?
>
> BTV. There is this old discussion when we discuss the "iframes" to be
> used for frontchannel logout rather than redirect based approach [2].
> You can see some more context by going through this old thread. I think
> that we already support iframe based frontchannel logout for SAML
> specification, or at least it is already available in Hynek's branch as
> mentioned in the comment of this JIRA [3]. So hopefully OIDC can re-use
> some parts of it.
>
> Let us know if you're interested in contributing this.
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-2939
> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.htm
> [3] https://issues.jboss.org/browse/KEYCLOAK-5449
>
> Marek
>
> On 10/03/2019 04:03, Diego Liberalquino wrote:
> > Hello,
> >
> > A thing that bothers me on Keycloak is the lack of implementation of
> > Front-Channel Logout for OpenID Clients. Is there any technical reason
> for
> > this or is just awaiting a community contribution? I mean, the spec is
> > supported for SAML clients, and it also works for external OIDC
> providers.
> >
> > Best regards,
> > Diego Liberalquino
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Mar 12 07:39:06 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Mar 2019 12:39:06 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
Message-ID: <CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>

It should be a pluggable part of the authentication flow and not a
hardcoded element. There is no other way to plug in to the authentication
flow other than creating an authenticator. An authenticator doesn't need to
provide a challenge though so it can be used in this instance.

On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com> wrote:

> Hello,
>
> I am sending this e-mail because I have some questions regarding the
> enhancement request that enables configurable session limiting in Keycloak
> as discussed here:
> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc
> Wijma
> referred to in his comment as being available for this task is me btw :))
>
> In the comments a solution is proposed that makes use of a custom
> Authenticator that is dropped into the authentication flow where it can be
> configured. While I can see the benefit of leveraging the existing
> components as much as possible (including the configuration options in that
> flow), I am wondering if this is the best solution. As far as I can tell,
> this component is not performing any authentication at all. Moreover this
> functionality operates 'above' the authentication mechanisms and should
> apply to all of them.
> So is an Authenticator really the desired place to implement this? Or is
> this just the quickest route, while not being the most desirable option for
> the long term? What would be an alternative approach be? That would place
> this implementation and configuration in the existing Session configuration
> code for instance.
>
> I just now started investigating this task and looking into the options
> that would meet our requirements. Hope to hear from you.
>
> Regards
>
> Mauro
>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From diegoliber at gmail.com  Tue Mar 12 08:12:30 2019
From: diegoliber at gmail.com (Diego Liberalquino)
Date: Tue, 12 Mar 2019 09:12:30 -0300
Subject: [keycloak-dev] Implementation of Front-Channel Logout for
 OpenID Connect clients
In-Reply-To: <CAK-7U1gbAv3Vag0soYiAtuPxw7Jnn43imvjFKBqOsSiHosrqdQ@mail.gmail.com>
References: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
	<4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>
	<CAK-7U1gbAv3Vag0soYiAtuPxw7Jnn43imvjFKBqOsSiHosrqdQ@mail.gmail.com>
Message-ID: <CAO0=Nf4GwRAOAkRhT9-71U+2W8StL=kzOFem85Y+7rWXEYmswA@mail.gmail.com>

Hi,

I want to make the contribution, yes. I'm very interested that this feature
gets implemented on Keycloak. It'll take some time though, I'm still
familiarizing myself with Keycloak's test suite, so I want to make sure my
contribution doesn't break anything.

I've read this discussion about iframe based logout on SAML and agree on
100% percent that the iframe-based approach is the best solution for this
problem and I was already getting inspiration from the SAML implementation.
OIDC FrontChannel Spec also expects the use of iframes [1].

Thanks for the follow up!

[1] https://openid.net/specs/openid-connect-frontchannel-1_0.html

Diego

On Tue, Mar 12, 2019 at 8:36 AM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Link to the discussion was broken:
> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.html
>
> Am Di., 12. M?rz 2019 um 12:30 Uhr schrieb Marek Posolda <
> mposolda at redhat.com>:
>
>> Hi,
>>
>> there is this JIRA opened already [1] . We have it planned, so we want
>> to look at it, but lack of other things caused that this wasn't
>> prioritized in last years... Do you want to contribute the feature?
>>
>> BTV. There is this old discussion when we discuss the "iframes" to be
>> used for frontchannel logout rather than redirect based approach [2].
>> You can see some more context by going through this old thread. I think
>> that we already support iframe based frontchannel logout for SAML
>> specification, or at least it is already available in Hynek's branch as
>> mentioned in the comment of this JIRA [3]. So hopefully OIDC can re-use
>> some parts of it.
>>
>> Let us know if you're interested in contributing this.
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-2939
>> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.htm
>> [3] https://issues.jboss.org/browse/KEYCLOAK-5449
>>
>> Marek
>>
>> On 10/03/2019 04:03, Diego Liberalquino wrote:
>> > Hello,
>> >
>> > A thing that bothers me on Keycloak is the lack of implementation of
>> > Front-Channel Logout for OpenID Clients. Is there any technical reason
>> for
>> > this or is just awaiting a community contribution? I mean, the spec is
>> > supported for SAML clients, and it also works for external OIDC
>> providers.
>> >
>> > Best regards,
>> > Diego Liberalquino
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.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 Mar 12 09:08:51 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 12 Mar 2019 14:08:51 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
 implicit flow
In-Reply-To: <284703E1-812B-4497-9F9C-84D263445D9E@n-k.de>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
	<031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
	<CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>
	<284703E1-812B-4497-9F9C-84D263445D9E@n-k.de>
Message-ID: <2981bb5d-6198-485a-9fc4-47053f692e0f@redhat.com>

Hi Niko,

Thanks for the PR! I've added some comment in the github.

Point taken regarding the tests. Maybe we have some space for 
improvement here. I personally trying to at least add some comments to 
the tests about what the test is doing etc. For example see 
OIDCScopeTest. Do you think it is sufficient for the 1st experience with 
the testsuite, or would you suggest to improve more?

Marek

On 11/03/2019 11:34, Niko K?bler wrote:
> Thanks Michal,
>
> thanks for the help.
> I struggled before with the notation from here https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-adapter-tests, as I needed to put the class name of the tests in quotes: -Dtest="org.keycloak.testsuite.adapter.**.*Test" - otherwise I got some shell errors.
>
> I just pushed the test, build is running.
> (It's like a nightmare to implement some tests, if you are not aware of all this stuff, as all your test classes are poorly (aka not-at-all) documented. If you want contributions from the community, you should change this!)
> Hope to get it merged soon. :)
>
> Regards,
> - Niko
>
>> Am 11.03.2019 um 09:45 schrieb Michal Hajas <mhajas at redhat.com>:
>>
>> Hello,
>>
>> thank you very much for the contribution.
>>
>> You can run JavascriptAdapterTest class using the following command executed from keycloak directory:
>>
>> mvn clean install -f testsuite/integration-arquillian/pom.xml -Dtest=JavascriptAdapterTest
>>
>> Best regards,
>> Michal
>>
>> On Sat, Mar 9, 2019 at 10:41 AM Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>> wrote:
>> I've just created a pull request for this issue, including docs, but still without tests.
>> https://github.com/keycloak/keycloak/pull/5932 <https://github.com/keycloak/keycloak/pull/5932>
>>
>> As the tests are quite complex to run, and I didn't find any information about how to run/execute just the JavascriptAdapterTest.java class without running the whole testsuite over and over again, I'd appreciate any help/hint, of how to run this test only.
>>
>> Thanks,
>> - Niko
>>
>>
>>
>>> Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>>:
>>>
>>> Hi team,
>>>
>>> I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 <https://issues.jboss.org/browse/KEYCLOAK-6795> as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
>>> I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
>>> Anybody interested in discussing?
>>>
>>> - Niko
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Tue Mar 12 09:16:03 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 12 Mar 2019 14:16:03 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
Message-ID: <aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>

Hi,

I already saw some request(s) in the past with regards to the 
GoogleIdentityProvider not provide same level of fine-grained 
configuration as the OIDC Identity provider. I think that generally it 
will be nice to remove this limitation(s) and hence allow some custom 
configurations to be done on the GoogleIdentityProvider as well.

So IMO the best would be the option (b) - just add the option to support 
forwarded parameters. This will probably allow best flexibility and 
hopefully the usability will be also fine.

Marek

On 12/03/2019 11:19, Francesco Degrassi wrote:
> Hello,
> we're testing Keycloak with Google as a social identity provider and using
> the token exchange functionality to get access to the IDP access token.
> I noticed that Google requires the access_type parameter to be set to
> "offline" in the call to the authorization endpoint to release a refresh
> token, but there is no easy way to do this in Keycloak; configuring a
> generic OIDC identity provider allows me to configure access_type as a
> forwarded parameter, but no such option exists using GoogleIdentityProvider.
>
> I have a patch that (a) modifies GoogleIdentityProviderConfig and overrides
> getForwardedParameters() to add "access_type" to the returned values.
>
> Other options I considered include (b) changing the UI to allow to
> configure the forwareded parameters for GoogleIdentityProvider (since it
> extends OidcIdentityProvider) or (c) add a boolean configuration option to
> GoogleIdentityProviderConfig to allow/disallow forwarding the parameter or
> (d) add a boolean configuration option to GoogleIdentityProviderConfig to
> set "access_type" to "offline" if checked.
>
> Which would be the preferred route? Would a pull request be accepted?
> Cheers.
>
> *Francesco Degrassi*
> Tech Lead
> +39 329 4128 422 <+39+329+4128+422>
> *OptionFactory <http://www.optionfactory.net/>*
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Tue Mar 12 09:38:02 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 12 Mar 2019 14:38:02 +0100
Subject: [keycloak-dev] PKCE in keycloak-servlet-oauth-client does not
 work
In-Reply-To: <CAJgngAdViNer97Yy0NXmn=vf+goSj36MZUjN9A6Ac+YPPkKbdQ@mail.gmail.com>
References: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAdViNer97Yy0NXmn=vf+goSj36MZUjN9A6Ac+YPPkKbdQ@mail.gmail.com>
Message-ID: <6875d5b0-784d-3e26-3b58-288b72760b1c@redhat.com>

It is a bit similar to recently deprecated JAXRS filter.

AFAIR it is one of the very early-days keycloak features and the 
use-case behind this was, that you have web frontend java application, 
which is not secured by Keycloak and doesn't use adapter. But you still 
want to have a way to invoke the REST services from this application, 
which are secured by Keycloak. So you want to trigger the OAuth flow 
manually from the Java without having the adapter to do it for you - 
that's what this client is doing.

I think that this client can be almost always replaced by adapter or by 
the servlet filter. The only case when it couldn't be replaced by 
servlet filter is, when you have non-servlet java application.

This OAuth client is unmaintained and it is missing lot of features, 
which were recently added to the adapter. I suggest to deprecate it and 
then remove in the future (or eventually move to the community 
maintained extension if people still wants to use it?)

Marek

On 08/03/2019 08:26, Stian Thorgersen wrote:
> I'm not sure what use-cases servlet-oauth-client aims to cover and I'm not
> sure why we have it in the first place. It's not documented nor is it well
> tested as far as I can tell.
>
> On Fri, 8 Mar 2019 at 03:26, ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
>
>> Hello,
>>
>> I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange)
>> support for keycloak and merged.
>> At that time, I had also implemented client side PKCE in servlet oauth
>> client to demonstrate how PKCE works.
>>
>> However, it seemed that I had pushed servlet oauth client codes that did
>> not work instead of ones used in my local environment.
>> Therefore, client side PKCE in servlet oauth client does not work.
>>
>> I've already known how to fix it, but it is difficult to write Arquillian
>> integration tests.
>>
>> I've searched existing Arquillian integration tests for servlet oauth
>> client but not found.
>>
>> Could anyone help me?
>>
>> Best regards,
>> Takashi Norimatsu
>> Hitachi Ltd.,
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.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 maurodewit at gmail.com  Tue Mar 12 09:53:45 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Tue, 12 Mar 2019 14:53:45 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
Message-ID: <CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>

Ok, thanks for the clarification.

On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com> wrote:

> It should be a pluggable part of the authentication flow and not a
> hardcoded element. There is no other way to plug in to the authentication
> flow other than creating an authenticator. An authenticator doesn't need to
> provide a challenge though so it can be used in this instance.
>
> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> Hello,
>>
>> I am sending this e-mail because I have some questions regarding the
>> enhancement request that enables configurable session limiting in Keycloak
>> as discussed here:
>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc
>> Wijma
>> referred to in his comment as being available for this task is me btw :))
>>
>> In the comments a solution is proposed that makes use of a custom
>> Authenticator that is dropped into the authentication flow where it can be
>> configured. While I can see the benefit of leveraging the existing
>> components as much as possible (including the configuration options in
>> that
>> flow), I am wondering if this is the best solution. As far as I can tell,
>> this component is not performing any authentication at all. Moreover this
>> functionality operates 'above' the authentication mechanisms and should
>> apply to all of them.
>> So is an Authenticator really the desired place to implement this? Or is
>> this just the quickest route, while not being the most desirable option
>> for
>> the long term? What would be an alternative approach be? That would place
>> this implementation and configuration in the existing Session
>> configuration
>> code for instance.
>>
>> I just now started investigating this task and looking into the options
>> that would meet our requirements. Hope to hear from you.
>>
>> Regards
>>
>> Mauro
>>
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Tue Mar 12 10:02:09 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Mar 2019 15:02:09 +0100
Subject: [keycloak-dev] PKCE in keycloak-servlet-oauth-client does not
	work
In-Reply-To: <6875d5b0-784d-3e26-3b58-288b72760b1c@redhat.com>
References: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAdViNer97Yy0NXmn=vf+goSj36MZUjN9A6Ac+YPPkKbdQ@mail.gmail.com>
	<6875d5b0-784d-3e26-3b58-288b72760b1c@redhat.com>
Message-ID: <CAJgngAdCAESwsMP_iZL7aU5PU1xRDn88maR+_7sdYwFkwQZPZQ@mail.gmail.com>

On Tue, 12 Mar 2019 at 14:38, Marek Posolda <mposolda at redhat.com> wrote:

> It is a bit similar to recently deprecated JAXRS filter.
>
> AFAIR it is one of the very early-days keycloak features and the
> use-case behind this was, that you have web frontend java application,
> which is not secured by Keycloak and doesn't use adapter. But you still
> want to have a way to invoke the REST services from this application,
> which are secured by Keycloak. So you want to trigger the OAuth flow
> manually from the Java without having the adapter to do it for you -
> that's what this client is doing.
>
> I think that this client can be almost always replaced by adapter or by
> the servlet filter. The only case when it couldn't be replaced by
> servlet filter is, when you have non-servlet java application.
>
> This OAuth client is unmaintained and it is missing lot of features,
> which were recently added to the adapter. I suggest to deprecate it and
> then remove in the future (or eventually move to the community
> maintained extension if people still wants to use it?)
>

+1


>
> Marek
>
> On 08/03/2019 08:26, Stian Thorgersen wrote:
> > I'm not sure what use-cases servlet-oauth-client aims to cover and I'm
> not
> > sure why we have it in the first place. It's not documented nor is it
> well
> > tested as far as I can tell.
> >
> > On Fri, 8 Mar 2019 at 03:26, ???? / NORIMATSU?TAKASHI <
> > takashi.norimatsu.ws at hitachi.com> wrote:
> >
> >> Hello,
> >>
> >> I had contributed server side PKCE (RFC 7636 Proof Key for Code
> Exchange)
> >> support for keycloak and merged.
> >> At that time, I had also implemented client side PKCE in servlet oauth
> >> client to demonstrate how PKCE works.
> >>
> >> However, it seemed that I had pushed servlet oauth client codes that did
> >> not work instead of ones used in my local environment.
> >> Therefore, client side PKCE in servlet oauth client does not work.
> >>
> >> I've already known how to fix it, but it is difficult to write
> Arquillian
> >> integration tests.
> >>
> >> I've searched existing Arquillian integration tests for servlet oauth
> >> client but not found.
> >>
> >> Could anyone help me?
> >>
> >> Best regards,
> >> Takashi Norimatsu
> >> Hitachi Ltd.,
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From sthorger at redhat.com  Tue Mar 12 10:09:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Mar 2019 15:09:35 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
Message-ID: <CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>

I'm not convinced about this approach for two reasons: it's not very
user-friendly and secondly it's not correct to request an offline token
unless you really need one.

Google doesn't use refresh tokens for regular sessions, but rather give you
a fairly long expiration token. As it's lacking the refresh token it means
you need to refresh the token with a redirect. This can be done with a
hidden iframe. So the correct approach here is to have the app refresh the
token by re-auth to KC  with a redirect (which can be in a hidden iframe).
This will do it in a proper way without using offline tokens.



On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> I already saw some request(s) in the past with regards to the
> GoogleIdentityProvider not provide same level of fine-grained
> configuration as the OIDC Identity provider. I think that generally it
> will be nice to remove this limitation(s) and hence allow some custom
> configurations to be done on the GoogleIdentityProvider as well.
>
> So IMO the best would be the option (b) - just add the option to support
> forwarded parameters. This will probably allow best flexibility and
> hopefully the usability will be also fine.
>
> Marek
>
> On 12/03/2019 11:19, Francesco Degrassi wrote:
> > Hello,
> > we're testing Keycloak with Google as a social identity provider and
> using
> > the token exchange functionality to get access to the IDP access token.
> > I noticed that Google requires the access_type parameter to be set to
> > "offline" in the call to the authorization endpoint to release a refresh
> > token, but there is no easy way to do this in Keycloak; configuring a
> > generic OIDC identity provider allows me to configure access_type as a
> > forwarded parameter, but no such option exists using
> GoogleIdentityProvider.
> >
> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
> overrides
> > getForwardedParameters() to add "access_type" to the returned values.
> >
> > Other options I considered include (b) changing the UI to allow to
> > configure the forwareded parameters for GoogleIdentityProvider (since it
> > extends OidcIdentityProvider) or (c) add a boolean configuration option
> to
> > GoogleIdentityProviderConfig to allow/disallow forwarding the parameter
> or
> > (d) add a boolean configuration option to GoogleIdentityProviderConfig to
> > set "access_type" to "offline" if checked.
> >
> > Which would be the preferred route? Would a pull request be accepted?
> > Cheers.
> >
> > *Francesco Degrassi*
> > Tech Lead
> > +39 329 4128 422 <+39+329+4128+422>
> > *OptionFactory <http://www.optionfactory.net/>*
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.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 francesco.degrassi at optionfactory.net  Tue Mar 12 10:27:21 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Tue, 12 Mar 2019 15:27:21 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
Message-ID: <CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>

I'm afraid I cannot agree, the key element is "unless you really need one".
The use case for access_type=offline is just that, in case you need to
refresh tokens offline (i.e. when the user is not at the browser).
Forbidding a use case explicitly allowed and supported by google cannot be
correct.

I agree with Marek about the fact that allowing users to configure
forwarded parameters is the simplest and more general solution, even though
it is not the most user-frlendly, since people might not know they need to
add access_type as a forwarded parameter. Maybe it can be mitigated through
documentation for Google Identity Provider.

Should I open a Jira before submitting a PR?
Cheers

*Francesco*

On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'm not convinced about this approach for two reasons: it's not very
> user-friendly and secondly it's not correct to request an offline token
> unless you really need one.
>
> Google doesn't use refresh tokens for regular sessions, but rather give
> you a fairly long expiration token. As it's lacking the refresh token it
> means you need to refresh the token with a redirect. This can be done with
> a hidden iframe. So the correct approach here is to have the app refresh
> the token by re-auth to KC  with a redirect (which can be in a hidden
> iframe). This will do it in a proper way without using offline tokens.
>
>
>
> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> I already saw some request(s) in the past with regards to the
>> GoogleIdentityProvider not provide same level of fine-grained
>> configuration as the OIDC Identity provider. I think that generally it
>> will be nice to remove this limitation(s) and hence allow some custom
>> configurations to be done on the GoogleIdentityProvider as well.
>>
>> So IMO the best would be the option (b) - just add the option to support
>> forwarded parameters. This will probably allow best flexibility and
>> hopefully the usability will be also fine.
>>
>> Marek
>>
>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>> > Hello,
>> > we're testing Keycloak with Google as a social identity provider and
>> using
>> > the token exchange functionality to get access to the IDP access token.
>> > I noticed that Google requires the access_type parameter to be set to
>> > "offline" in the call to the authorization endpoint to release a refresh
>> > token, but there is no easy way to do this in Keycloak; configuring a
>> > generic OIDC identity provider allows me to configure access_type as a
>> > forwarded parameter, but no such option exists using
>> GoogleIdentityProvider.
>> >
>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>> overrides
>> > getForwardedParameters() to add "access_type" to the returned values.
>> >
>> > Other options I considered include (b) changing the UI to allow to
>> > configure the forwareded parameters for GoogleIdentityProvider (since it
>> > extends OidcIdentityProvider) or (c) add a boolean configuration option
>> to
>> > GoogleIdentityProviderConfig to allow/disallow forwarding the parameter
>> or
>> > (d) add a boolean configuration option to GoogleIdentityProviderConfig
>> to
>> > set "access_type" to "offline" if checked.
>> >
>> > Which would be the preferred route? Would a pull request be accepted?
>> > Cheers.
>> >
>> > *Francesco Degrassi*
>> > Tech Lead
>> > +39 329 4128 422 <+39+329+4128+422>
>> > *OptionFactory <http://www.optionfactory.net/>*
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Tue Mar 12 13:54:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Mar 2019 18:54:11 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
Message-ID: <CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>

Are you using offline tokens from Keycloak that are being exchanged for
offline tokens from Google? Or is it what I suspect that you have a user
logged-in through Google and you want to access something in Google APIs
while the user is logged-in?

On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
francesco.degrassi at optionfactory.net> wrote:

> I'm afraid I cannot agree, the key element is "unless you really need
> one".
> The use case for access_type=offline is just that, in case you need to
> refresh tokens offline (i.e. when the user is not at the browser).
> Forbidding a use case explicitly allowed and supported by google cannot be
> correct.
>
> I agree with Marek about the fact that allowing users to configure
> forwarded parameters is the simplest and more general solution, even though
> it is not the most user-frlendly, since people might not know they need to
> add access_type as a forwarded parameter. Maybe it can be mitigated through
> documentation for Google Identity Provider.
>
> Should I open a Jira before submitting a PR?
> Cheers
>
> *Francesco*
>
> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I'm not convinced about this approach for two reasons: it's not very
>> user-friendly and secondly it's not correct to request an offline token
>> unless you really need one.
>>
>> Google doesn't use refresh tokens for regular sessions, but rather give
>> you a fairly long expiration token. As it's lacking the refresh token it
>> means you need to refresh the token with a redirect. This can be done with
>> a hidden iframe. So the correct approach here is to have the app refresh
>> the token by re-auth to KC  with a redirect (which can be in a hidden
>> iframe). This will do it in a proper way without using offline tokens.
>>
>>
>>
>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I already saw some request(s) in the past with regards to the
>>> GoogleIdentityProvider not provide same level of fine-grained
>>> configuration as the OIDC Identity provider. I think that generally it
>>> will be nice to remove this limitation(s) and hence allow some custom
>>> configurations to be done on the GoogleIdentityProvider as well.
>>>
>>> So IMO the best would be the option (b) - just add the option to support
>>> forwarded parameters. This will probably allow best flexibility and
>>> hopefully the usability will be also fine.
>>>
>>> Marek
>>>
>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>> > Hello,
>>> > we're testing Keycloak with Google as a social identity provider and
>>> using
>>> > the token exchange functionality to get access to the IDP access token.
>>> > I noticed that Google requires the access_type parameter to be set to
>>> > "offline" in the call to the authorization endpoint to release a
>>> refresh
>>> > token, but there is no easy way to do this in Keycloak; configuring a
>>> > generic OIDC identity provider allows me to configure access_type as a
>>> > forwarded parameter, but no such option exists using
>>> GoogleIdentityProvider.
>>> >
>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>> overrides
>>> > getForwardedParameters() to add "access_type" to the returned values.
>>> >
>>> > Other options I considered include (b) changing the UI to allow to
>>> > configure the forwareded parameters for GoogleIdentityProvider (since
>>> it
>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>> option to
>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>> parameter or
>>> > (d) add a boolean configuration option to GoogleIdentityProviderConfig
>>> to
>>> > set "access_type" to "offline" if checked.
>>> >
>>> > Which would be the preferred route? Would a pull request be accepted?
>>> > Cheers.
>>> >
>>> > *Francesco Degrassi*
>>> > Tech Lead
>>> > +39 329 4128 422 <+39+329+4128+422>
>>> > *OptionFactory <http://www.optionfactory.net/>*
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Tue Mar 12 13:57:07 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Mar 2019 18:57:07 +0100
Subject: [keycloak-dev] Implementation of Front-Channel Logout for
 OpenID Connect clients
In-Reply-To: <CAO0=Nf4GwRAOAkRhT9-71U+2W8StL=kzOFem85Y+7rWXEYmswA@mail.gmail.com>
References: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
	<4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>
	<CAK-7U1gbAv3Vag0soYiAtuPxw7Jnn43imvjFKBqOsSiHosrqdQ@mail.gmail.com>
	<CAO0=Nf4GwRAOAkRhT9-71U+2W8StL=kzOFem85Y+7rWXEYmswA@mail.gmail.com>
Message-ID: <CAJgngAeroemi9y4nSs-KQgWuRL+B8k97CXdQqRZ5YMhfSKs5=g@mail.gmail.com>

I have my worries about this spec. It was proposed back in Jan 2017 and is
still in draft state. It seems to be abandoned.

Before adding support for this spec we should look for alternatives and
check what the status is of the spec and why nothing is happening with it.

On Tue, 12 Mar 2019 at 13:16, Diego Liberalquino <diegoliber at gmail.com>
wrote:

> Hi,
>
> I want to make the contribution, yes. I'm very interested that this feature
> gets implemented on Keycloak. It'll take some time though, I'm still
> familiarizing myself with Keycloak's test suite, so I want to make sure my
> contribution doesn't break anything.
>
> I've read this discussion about iframe based logout on SAML and agree on
> 100% percent that the iframe-based approach is the best solution for this
> problem and I was already getting inspiration from the SAML implementation.
> OIDC FrontChannel Spec also expects the use of iframes [1].
>
> Thanks for the follow up!
>
> [1] https://openid.net/specs/openid-connect-frontchannel-1_0.html
>
> Diego
>
> On Tue, Mar 12, 2019 at 8:36 AM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
> > Link to the discussion was broken:
> > [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.html
> >
> > Am Di., 12. M?rz 2019 um 12:30 Uhr schrieb Marek Posolda <
> > mposolda at redhat.com>:
> >
> >> Hi,
> >>
> >> there is this JIRA opened already [1] . We have it planned, so we want
> >> to look at it, but lack of other things caused that this wasn't
> >> prioritized in last years... Do you want to contribute the feature?
> >>
> >> BTV. There is this old discussion when we discuss the "iframes" to be
> >> used for frontchannel logout rather than redirect based approach [2].
> >> You can see some more context by going through this old thread. I think
> >> that we already support iframe based frontchannel logout for SAML
> >> specification, or at least it is already available in Hynek's branch as
> >> mentioned in the comment of this JIRA [3]. So hopefully OIDC can re-use
> >> some parts of it.
> >>
> >> Let us know if you're interested in contributing this.
> >>
> >> [1] https://issues.jboss.org/browse/KEYCLOAK-2939
> >> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.htm
> >> [3] https://issues.jboss.org/browse/KEYCLOAK-5449
> >>
> >> Marek
> >>
> >> On 10/03/2019 04:03, Diego Liberalquino wrote:
> >> > Hello,
> >> >
> >> > A thing that bothers me on Keycloak is the lack of implementation of
> >> > Front-Channel Logout for OpenID Clients. Is there any technical reason
> >> for
> >> > this or is just awaiting a community contribution? I mean, the spec is
> >> > supported for SAML clients, and it also works for external OIDC
> >> providers.
> >> >
> >> > Best regards,
> >> > Diego Liberalquino
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.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 francesco.degrassi at optionfactory.net  Tue Mar 12 14:20:06 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Tue, 12 Mar 2019 19:20:06 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
Message-ID: <CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>

We're logging users in through multiple identity providers configured on
keycloak.
Regardless of the idp used, the user can link their Google account (if they
logged through a different idp) to have the application poll Google APIs
periodically.

Cheers

On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com> wrote:

> Are you using offline tokens from Keycloak that are being exchanged for
> offline tokens from Google? Or is it what I suspect that you have a user
> logged-in through Google and you want to access something in Google APIs
> while the user is logged-in?
>
> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
> francesco.degrassi at optionfactory.net> wrote:
>
>> I'm afraid I cannot agree, the key element is "unless you really need
>> one".
>> The use case for access_type=offline is just that, in case you need to
>> refresh tokens offline (i.e. when the user is not at the browser).
>> Forbidding a use case explicitly allowed and supported by google cannot
>> be correct.
>>
>> I agree with Marek about the fact that allowing users to configure
>> forwarded parameters is the simplest and more general solution, even though
>> it is not the most user-frlendly, since people might not know they need to
>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>> documentation for Google Identity Provider.
>>
>> Should I open a Jira before submitting a PR?
>> Cheers
>>
>> *Francesco*
>>
>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I'm not convinced about this approach for two reasons: it's not very
>>> user-friendly and secondly it's not correct to request an offline token
>>> unless you really need one.
>>>
>>> Google doesn't use refresh tokens for regular sessions, but rather give
>>> you a fairly long expiration token. As it's lacking the refresh token it
>>> means you need to refresh the token with a redirect. This can be done with
>>> a hidden iframe. So the correct approach here is to have the app refresh
>>> the token by re-auth to KC  with a redirect (which can be in a hidden
>>> iframe). This will do it in a proper way without using offline tokens.
>>>
>>>
>>>
>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I already saw some request(s) in the past with regards to the
>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>> configuration as the OIDC Identity provider. I think that generally it
>>>> will be nice to remove this limitation(s) and hence allow some custom
>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>
>>>> So IMO the best would be the option (b) - just add the option to
>>>> support
>>>> forwarded parameters. This will probably allow best flexibility and
>>>> hopefully the usability will be also fine.
>>>>
>>>> Marek
>>>>
>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>> > Hello,
>>>> > we're testing Keycloak with Google as a social identity provider and
>>>> using
>>>> > the token exchange functionality to get access to the IDP access
>>>> token.
>>>> > I noticed that Google requires the access_type parameter to be set to
>>>> > "offline" in the call to the authorization endpoint to release a
>>>> refresh
>>>> > token, but there is no easy way to do this in Keycloak; configuring a
>>>> > generic OIDC identity provider allows me to configure access_type as a
>>>> > forwarded parameter, but no such option exists using
>>>> GoogleIdentityProvider.
>>>> >
>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>>> overrides
>>>> > getForwardedParameters() to add "access_type" to the returned values.
>>>> >
>>>> > Other options I considered include (b) changing the UI to allow to
>>>> > configure the forwareded parameters for GoogleIdentityProvider (since
>>>> it
>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>> option to
>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>> parameter or
>>>> > (d) add a boolean configuration option to
>>>> GoogleIdentityProviderConfig to
>>>> > set "access_type" to "offline" if checked.
>>>> >
>>>> > Which would be the preferred route? Would a pull request be accepted?
>>>> > Cheers.
>>>> >
>>>> > *Francesco Degrassi*
>>>> > Tech Lead
>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>> > _______________________________________________
>>>> > keycloak-dev mailing list
>>>> > keycloak-dev at lists.jboss.org
>>>> > https://lists.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 niko at n-k.de  Tue Mar 12 14:55:38 2019
From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=)
Date: Tue, 12 Mar 2019 19:55:38 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
 implicit flow
In-Reply-To: <2981bb5d-6198-485a-9fc4-47053f692e0f@redhat.com>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
	<031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
	<CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>
	<284703E1-812B-4497-9F9C-84D263445D9E@n-k.de>
	<2981bb5d-6198-485a-9fc4-47053f692e0f@redhat.com>
Message-ID: <A28D863D-C565-4400-8FC5-706EA639102C@n-k.de>

Hi Marek,

my point was not about the comments what the test is doing - that's something I can read from the code (and hopefully from a good test method name). However, every comment might be helpful.
I struggled most with JavascriptAdapterTest to figure out, what resources I need else to execute/modify/improve the tests. So it took me half an hour to an hour to figure out, that the TestJavascriptResource class is also "part of" the test. It's located in a completely different subfolder from the actual test:

testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/adapter/javascript/JavascriptAdapterTest.java
vs.
testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/rest/resource/TestJavascriptResource.java

You see!? It starts to differ at the 3rd folder level - and then it gets deeper, and deeper, and... ;)
And I didn't find a good documentation about how the testsuite is structured and organized.

- Niko


> Am 12.03.2019 um 14:08 schrieb Marek Posolda <mposolda at redhat.com>:
> 
> Hi Niko,
> 
> Thanks for the PR! I've added some comment in the github.
> 
> Point taken regarding the tests. Maybe we have some space for improvement here. I personally trying to at least add some comments to the tests about what the test is doing etc. For example see OIDCScopeTest. Do you think it is sufficient for the 1st experience with the testsuite, or would you suggest to improve more?
> 
> Marek
> 
> On 11/03/2019 11:34, Niko K?bler wrote:
>> Thanks Michal,
>> 
>> thanks for the help.
>> I struggled before with the notation from here https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-adapter-tests, as I needed to put the class name of the tests in quotes: -Dtest="org.keycloak.testsuite.adapter.**.*Test" - otherwise I got some shell errors.
>> 
>> I just pushed the test, build is running.
>> (It's like a nightmare to implement some tests, if you are not aware of all this stuff, as all your test classes are poorly (aka not-at-all) documented. If you want contributions from the community, you should change this!)
>> Hope to get it merged soon. :)
>> 
>> Regards,
>> - Niko
>> 
>>> Am 11.03.2019 um 09:45 schrieb Michal Hajas <mhajas at redhat.com>:
>>> 
>>> Hello,
>>> 
>>> thank you very much for the contribution.
>>> 
>>> You can run JavascriptAdapterTest class using the following command executed from keycloak directory:
>>> 
>>> mvn clean install -f testsuite/integration-arquillian/pom.xml -Dtest=JavascriptAdapterTest
>>> 
>>> Best regards,
>>> Michal
>>> 
>>> On Sat, Mar 9, 2019 at 10:41 AM Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>> wrote:
>>> I've just created a pull request for this issue, including docs, but still without tests.
>>> https://github.com/keycloak/keycloak/pull/5932 <https://github.com/keycloak/keycloak/pull/5932>
>>> 
>>> As the tests are quite complex to run, and I didn't find any information about how to run/execute just the JavascriptAdapterTest.java class without running the whole testsuite over and over again, I'd appreciate any help/hint, of how to run this test only.
>>> 
>>> Thanks,
>>> - Niko
>>> 
>>> 
>>> 
>>>> Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>>:
>>>> 
>>>> Hi team,
>>>> 
>>>> I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 <https://issues.jboss.org/browse/KEYCLOAK-6795> as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
>>>> I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
>>>> Anybody interested in discussing?
>>>> 
>>>> - Niko
>>>> 
>>>> 
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 



From downs at mythical.games  Tue Mar 12 15:00:10 2019
From: downs at mythical.games (Chris Downs)
Date: Tue, 12 Mar 2019 12:00:10 -0700
Subject: [keycloak-dev] jaxrs-oauth-client deprecation question
Message-ID: <ab4fb9c0-6d76-489b-f22b-ffba2044bad1@mythical.games>

Hello!

I noticed that jaxrs-oauth-client is marked as deprecated in master. Is 
this deprecation in favor of something better, or do you just not want 
to maintain it anymore? Asking because I'm adding keycloak authn/z to a 
dropwizard jaxrs project which was going to be based off of this, but 
don't want to move forward with something that is going away if there is 
a better option.

Thanks,

Chris Downs

From francesco.degrassi at optionfactory.net  Tue Mar 12 16:25:50 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Tue, 12 Mar 2019 21:25:50 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
Message-ID: <CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>

Hello again, Stian.
Putting my specific use-case aside for a minute, do you see a specific
reason not to allow users to configure finer-grained OIDCIdentityProvider
options such as forwarded parameters for well-known, first-party supported,
OIDC compliant social login Identity Providers such as Google?

*Francesco *

On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
francesco.degrassi at optionfactory.net> wrote:

> We're logging users in through multiple identity providers configured on
> keycloak.
> Regardless of the idp used, the user can link their Google account (if
> they logged through a different idp) to have the application poll Google
> APIs periodically.
>
> Cheers
>
> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com> wrote:
>
>> Are you using offline tokens from Keycloak that are being exchanged for
>> offline tokens from Google? Or is it what I suspect that you have a user
>> logged-in through Google and you want to access something in Google APIs
>> while the user is logged-in?
>>
>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>> francesco.degrassi at optionfactory.net> wrote:
>>
>>> I'm afraid I cannot agree, the key element is "unless you really need
>>> one".
>>> The use case for access_type=offline is just that, in case you need to
>>> refresh tokens offline (i.e. when the user is not at the browser).
>>> Forbidding a use case explicitly allowed and supported by google cannot
>>> be correct.
>>>
>>> I agree with Marek about the fact that allowing users to configure
>>> forwarded parameters is the simplest and more general solution, even though
>>> it is not the most user-frlendly, since people might not know they need to
>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>> documentation for Google Identity Provider.
>>>
>>> Should I open a Jira before submitting a PR?
>>> Cheers
>>>
>>> *Francesco*
>>>
>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> I'm not convinced about this approach for two reasons: it's not very
>>>> user-friendly and secondly it's not correct to request an offline token
>>>> unless you really need one.
>>>>
>>>> Google doesn't use refresh tokens for regular sessions, but rather give
>>>> you a fairly long expiration token. As it's lacking the refresh token it
>>>> means you need to refresh the token with a redirect. This can be done with
>>>> a hidden iframe. So the correct approach here is to have the app refresh
>>>> the token by re-auth to KC  with a redirect (which can be in a hidden
>>>> iframe). This will do it in a proper way without using offline tokens.
>>>>
>>>>
>>>>
>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I already saw some request(s) in the past with regards to the
>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>> configuration as the OIDC Identity provider. I think that generally it
>>>>> will be nice to remove this limitation(s) and hence allow some custom
>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>
>>>>> So IMO the best would be the option (b) - just add the option to
>>>>> support
>>>>> forwarded parameters. This will probably allow best flexibility and
>>>>> hopefully the usability will be also fine.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>> > Hello,
>>>>> > we're testing Keycloak with Google as a social identity provider and
>>>>> using
>>>>> > the token exchange functionality to get access to the IDP access
>>>>> token.
>>>>> > I noticed that Google requires the access_type parameter to be set to
>>>>> > "offline" in the call to the authorization endpoint to release a
>>>>> refresh
>>>>> > token, but there is no easy way to do this in Keycloak; configuring a
>>>>> > generic OIDC identity provider allows me to configure access_type as
>>>>> a
>>>>> > forwarded parameter, but no such option exists using
>>>>> GoogleIdentityProvider.
>>>>> >
>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>>>> overrides
>>>>> > getForwardedParameters() to add "access_type" to the returned values.
>>>>> >
>>>>> > Other options I considered include (b) changing the UI to allow to
>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>> (since it
>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>>> option to
>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>> parameter or
>>>>> > (d) add a boolean configuration option to
>>>>> GoogleIdentityProviderConfig to
>>>>> > set "access_type" to "offline" if checked.
>>>>> >
>>>>> > Which would be the preferred route? Would a pull request be accepted?
>>>>> > Cheers.
>>>>> >
>>>>> > *Francesco Degrassi*
>>>>> > Tech Lead
>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>> > _______________________________________________
>>>>> > keycloak-dev mailing list
>>>>> > keycloak-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From sthorger at redhat.com  Wed Mar 13 05:13:59 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Mar 2019 10:13:59 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
Message-ID: <CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>

End of the day we are trying to make Keycloak user friendly and having too
many configuration options and tweaks doesn't help with that, especially
config options like what is being proposed at the moment that requires
users to know specific query parameters from Google.

I'd rather see either this somehow automatically being figured out by
Keycloak or a more high level config option being introduced. That is why
I'm asking for details on your use-case and not just accepting a low level
config option to be added without discussion.

I don't think we will know if/when an offline token is needed
automatically, so should rather look at adding an option to request offline
token. With OIDC that's done through scope offline, but it seems Google has
decided not to follow the spec, but rather do their own thing.



On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
francesco.degrassi at optionfactory.net> wrote:

> Hello again, Stian.
> Putting my specific use-case aside for a minute, do you see a specific
> reason not to allow users to configure finer-grained OIDCIdentityProvider
> options such as forwarded parameters for well-known, first-party supported,
> OIDC compliant social login Identity Providers such as Google?
>
> *Francesco *
>
> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
> francesco.degrassi at optionfactory.net> wrote:
>
>> We're logging users in through multiple identity providers configured on
>> keycloak.
>> Regardless of the idp used, the user can link their Google account (if
>> they logged through a different idp) to have the application poll Google
>> APIs periodically.
>>
>> Cheers
>>
>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com> wrote:
>>
>>> Are you using offline tokens from Keycloak that are being exchanged for
>>> offline tokens from Google? Or is it what I suspect that you have a user
>>> logged-in through Google and you want to access something in Google APIs
>>> while the user is logged-in?
>>>
>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>> francesco.degrassi at optionfactory.net> wrote:
>>>
>>>> I'm afraid I cannot agree, the key element is "unless you really need
>>>> one".
>>>> The use case for access_type=offline is just that, in case you need to
>>>> refresh tokens offline (i.e. when the user is not at the browser).
>>>> Forbidding a use case explicitly allowed and supported by google cannot
>>>> be correct.
>>>>
>>>> I agree with Marek about the fact that allowing users to configure
>>>> forwarded parameters is the simplest and more general solution, even though
>>>> it is not the most user-frlendly, since people might not know they need to
>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>> documentation for Google Identity Provider.
>>>>
>>>> Should I open a Jira before submitting a PR?
>>>> Cheers
>>>>
>>>> *Francesco*
>>>>
>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> I'm not convinced about this approach for two reasons: it's not very
>>>>> user-friendly and secondly it's not correct to request an offline token
>>>>> unless you really need one.
>>>>>
>>>>> Google doesn't use refresh tokens for regular sessions, but rather
>>>>> give you a fairly long expiration token. As it's lacking the refresh token
>>>>> it means you need to refresh the token with a redirect. This can be done
>>>>> with a hidden iframe. So the correct approach here is to have the app
>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>> tokens.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I already saw some request(s) in the past with regards to the
>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>> configuration as the OIDC Identity provider. I think that generally
>>>>>> it
>>>>>> will be nice to remove this limitation(s) and hence allow some custom
>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>
>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>> support
>>>>>> forwarded parameters. This will probably allow best flexibility and
>>>>>> hopefully the usability will be also fine.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>> > Hello,
>>>>>> > we're testing Keycloak with Google as a social identity provider
>>>>>> and using
>>>>>> > the token exchange functionality to get access to the IDP access
>>>>>> token.
>>>>>> > I noticed that Google requires the access_type parameter to be set
>>>>>> to
>>>>>> > "offline" in the call to the authorization endpoint to release a
>>>>>> refresh
>>>>>> > token, but there is no easy way to do this in Keycloak; configuring
>>>>>> a
>>>>>> > generic OIDC identity provider allows me to configure access_type
>>>>>> as a
>>>>>> > forwarded parameter, but no such option exists using
>>>>>> GoogleIdentityProvider.
>>>>>> >
>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>>>>> overrides
>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>> values.
>>>>>> >
>>>>>> > Other options I considered include (b) changing the UI to allow to
>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>> (since it
>>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>>>> option to
>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>> parameter or
>>>>>> > (d) add a boolean configuration option to
>>>>>> GoogleIdentityProviderConfig to
>>>>>> > set "access_type" to "offline" if checked.
>>>>>> >
>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>> accepted?
>>>>>> > Cheers.
>>>>>> >
>>>>>> > *Francesco Degrassi*
>>>>>> > Tech Lead
>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>> > _______________________________________________
>>>>>> > keycloak-dev mailing list
>>>>>> > keycloak-dev at lists.jboss.org
>>>>>> > https://lists.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 francesco.degrassi at optionfactory.net  Wed Mar 13 05:39:00 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Wed, 13 Mar 2019 10:39:00 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
	<CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
Message-ID: <CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>

I understand.
Taking this into consideration, I'd propose to add a high-level config
option "offline access" to the Google Identity Provider configuration, a
dropdown with three possible values:
- never request offline access (which is the current behavior)
- always request offline access (which always adds the access_type=offline
to the authorization request to google)
- allow offline access to be requested by clients (with docs explaining
that clients can pass a access_type=offline parameter if they want refresh
tokens from google), which adds access_type as a forwarded parameter

This should be easy to use and support all possible use cases; would you
support something of the sort?
Cheers

*Francesco*


On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger at redhat.com> wrote:

> End of the day we are trying to make Keycloak user friendly and having too
> many configuration options and tweaks doesn't help with that, especially
> config options like what is being proposed at the moment that requires
> users to know specific query parameters from Google.
>
> I'd rather see either this somehow automatically being figured out by
> Keycloak or a more high level config option being introduced. That is why
> I'm asking for details on your use-case and not just accepting a low level
> config option to be added without discussion.
>
> I don't think we will know if/when an offline token is needed
> automatically, so should rather look at adding an option to request offline
> token. With OIDC that's done through scope offline, but it seems Google has
> decided not to follow the spec, but rather do their own thing.
>
>
>
> On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
> francesco.degrassi at optionfactory.net> wrote:
>
>> Hello again, Stian.
>> Putting my specific use-case aside for a minute, do you see a specific
>> reason not to allow users to configure finer-grained OIDCIdentityProvider
>> options such as forwarded parameters for well-known, first-party supported,
>> OIDC compliant social login Identity Providers such as Google?
>>
>> *Francesco *
>>
>> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
>> francesco.degrassi at optionfactory.net> wrote:
>>
>>> We're logging users in through multiple identity providers configured on
>>> keycloak.
>>> Regardless of the idp used, the user can link their Google account (if
>>> they logged through a different idp) to have the application poll Google
>>> APIs periodically.
>>>
>>> Cheers
>>>
>>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Are you using offline tokens from Keycloak that are being exchanged for
>>>> offline tokens from Google? Or is it what I suspect that you have a user
>>>> logged-in through Google and you want to access something in Google APIs
>>>> while the user is logged-in?
>>>>
>>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>
>>>>> I'm afraid I cannot agree, the key element is "unless you really need
>>>>> one".
>>>>> The use case for access_type=offline is just that, in case you need to
>>>>> refresh tokens offline (i.e. when the user is not at the browser).
>>>>> Forbidding a use case explicitly allowed and supported by google
>>>>> cannot be correct.
>>>>>
>>>>> I agree with Marek about the fact that allowing users to configure
>>>>> forwarded parameters is the simplest and more general solution, even though
>>>>> it is not the most user-frlendly, since people might not know they need to
>>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>>> documentation for Google Identity Provider.
>>>>>
>>>>> Should I open a Jira before submitting a PR?
>>>>> Cheers
>>>>>
>>>>> *Francesco*
>>>>>
>>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I'm not convinced about this approach for two reasons: it's not very
>>>>>> user-friendly and secondly it's not correct to request an offline token
>>>>>> unless you really need one.
>>>>>>
>>>>>> Google doesn't use refresh tokens for regular sessions, but rather
>>>>>> give you a fairly long expiration token. As it's lacking the refresh token
>>>>>> it means you need to refresh the token with a redirect. This can be done
>>>>>> with a hidden iframe. So the correct approach here is to have the app
>>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>>> tokens.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I already saw some request(s) in the past with regards to the
>>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>>> configuration as the OIDC Identity provider. I think that generally
>>>>>>> it
>>>>>>> will be nice to remove this limitation(s) and hence allow some
>>>>>>> custom
>>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>>
>>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>>> support
>>>>>>> forwarded parameters. This will probably allow best flexibility and
>>>>>>> hopefully the usability will be also fine.
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>>> > Hello,
>>>>>>> > we're testing Keycloak with Google as a social identity provider
>>>>>>> and using
>>>>>>> > the token exchange functionality to get access to the IDP access
>>>>>>> token.
>>>>>>> > I noticed that Google requires the access_type parameter to be set
>>>>>>> to
>>>>>>> > "offline" in the call to the authorization endpoint to release a
>>>>>>> refresh
>>>>>>> > token, but there is no easy way to do this in Keycloak;
>>>>>>> configuring a
>>>>>>> > generic OIDC identity provider allows me to configure access_type
>>>>>>> as a
>>>>>>> > forwarded parameter, but no such option exists using
>>>>>>> GoogleIdentityProvider.
>>>>>>> >
>>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>>>>>> overrides
>>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>>> values.
>>>>>>> >
>>>>>>> > Other options I considered include (b) changing the UI to allow to
>>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>>> (since it
>>>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>>>>> option to
>>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>>> parameter or
>>>>>>> > (d) add a boolean configuration option to
>>>>>>> GoogleIdentityProviderConfig to
>>>>>>> > set "access_type" to "offline" if checked.
>>>>>>> >
>>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>>> accepted?
>>>>>>> > Cheers.
>>>>>>> >
>>>>>>> > *Francesco Degrassi*
>>>>>>> > Tech Lead
>>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>>> > _______________________________________________
>>>>>>> > keycloak-dev mailing list
>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>> > https://lists.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 vramik at redhat.com  Wed Mar 13 07:36:27 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Wed, 13 Mar 2019 12:36:27 +0100
Subject: [keycloak-dev] jaxrs-oauth-client deprecation question
In-Reply-To: <ab4fb9c0-6d76-489b-f22b-ffba2044bad1@mythical.games>
References: <ab4fb9c0-6d76-489b-f22b-ffba2044bad1@mythical.games>
Message-ID: <06e61af6-fa40-2803-5d97-cad20fe5d368@redhat.com>

Hello Chris,

for further info please check the "Removing JaxrsBearerTokenFilter" 
thread here on keycloak-dev mailing list.

V.

On 3/12/19 8:00 PM, Chris Downs wrote:
> Hello!
>
> I noticed that jaxrs-oauth-client is marked as deprecated in master. Is
> this deprecation in favor of something better, or do you just not want
> to maintain it anymore? Asking because I'm adding keycloak authn/z to a
> dropwizard jaxrs project which was going to be based off of this, but
> don't want to move forward with something that is going away if there is
> a better option.
>
> Thanks,
>
> Chris Downs
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Mar 13 07:59:55 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Mar 2019 12:59:55 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
	<CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
	<CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>
Message-ID: <CAJgngAfzXzVuNfW0enk+ixiSoJy7ZjRRT93jRbXrkJTG0_kciQ@mail.gmail.com>

On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi <
francesco.degrassi at optionfactory.net> wrote:

> I understand.
> Taking this into consideration, I'd propose to add a high-level config
> option "offline access" to the Google Identity Provider configuration, a
> dropdown with three possible values:
> - never request offline access (which is the current behavior)
> - always request offline access (which always adds the access_type=offline
> to the authorization request to google)
> - allow offline access to be requested by clients (with docs explaining
> that clients can pass a access_type=offline parameter if they want refresh
> tokens from google), which adds access_type as a forwarded parameter
>

I'm not convinced about the last option. When would you use that? Clients
talk to KC, not Google. KC doesn't support access_type=offline so makes no
sense that the client would use that.


>
> This should be easy to use and support all possible use cases; would you
> support something of the sort?
> Cheers
>
> *Francesco*
>
>
> On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> End of the day we are trying to make Keycloak user friendly and having
>> too many configuration options and tweaks doesn't help with that,
>> especially config options like what is being proposed at the moment that
>> requires users to know specific query parameters from Google.
>>
>> I'd rather see either this somehow automatically being figured out by
>> Keycloak or a more high level config option being introduced. That is why
>> I'm asking for details on your use-case and not just accepting a low level
>> config option to be added without discussion.
>>
>> I don't think we will know if/when an offline token is needed
>> automatically, so should rather look at adding an option to request offline
>> token. With OIDC that's done through scope offline, but it seems Google has
>> decided not to follow the spec, but rather do their own thing.
>>
>>
>>
>> On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
>> francesco.degrassi at optionfactory.net> wrote:
>>
>>> Hello again, Stian.
>>> Putting my specific use-case aside for a minute, do you see a specific
>>> reason not to allow users to configure finer-grained OIDCIdentityProvider
>>> options such as forwarded parameters for well-known, first-party supported,
>>> OIDC compliant social login Identity Providers such as Google?
>>>
>>> *Francesco *
>>>
>>> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
>>> francesco.degrassi at optionfactory.net> wrote:
>>>
>>>> We're logging users in through multiple identity providers configured
>>>> on keycloak.
>>>> Regardless of the idp used, the user can link their Google account (if
>>>> they logged through a different idp) to have the application poll Google
>>>> APIs periodically.
>>>>
>>>> Cheers
>>>>
>>>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Are you using offline tokens from Keycloak that are being exchanged
>>>>> for offline tokens from Google? Or is it what I suspect that you have a
>>>>> user logged-in through Google and you want to access something in Google
>>>>> APIs while the user is logged-in?
>>>>>
>>>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>
>>>>>> I'm afraid I cannot agree, the key element is "unless you really need
>>>>>> one".
>>>>>> The use case for access_type=offline is just that, in case you need
>>>>>> to refresh tokens offline (i.e. when the user is not at the browser).
>>>>>> Forbidding a use case explicitly allowed and supported by google
>>>>>> cannot be correct.
>>>>>>
>>>>>> I agree with Marek about the fact that allowing users to configure
>>>>>> forwarded parameters is the simplest and more general solution, even though
>>>>>> it is not the most user-frlendly, since people might not know they need to
>>>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>>>> documentation for Google Identity Provider.
>>>>>>
>>>>>> Should I open a Jira before submitting a PR?
>>>>>> Cheers
>>>>>>
>>>>>> *Francesco*
>>>>>>
>>>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm not convinced about this approach for two reasons: it's not very
>>>>>>> user-friendly and secondly it's not correct to request an offline token
>>>>>>> unless you really need one.
>>>>>>>
>>>>>>> Google doesn't use refresh tokens for regular sessions, but rather
>>>>>>> give you a fairly long expiration token. As it's lacking the refresh token
>>>>>>> it means you need to refresh the token with a redirect. This can be done
>>>>>>> with a hidden iframe. So the correct approach here is to have the app
>>>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>>>> tokens.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I already saw some request(s) in the past with regards to the
>>>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>>>> configuration as the OIDC Identity provider. I think that generally
>>>>>>>> it
>>>>>>>> will be nice to remove this limitation(s) and hence allow some
>>>>>>>> custom
>>>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>>>
>>>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>>>> support
>>>>>>>> forwarded parameters. This will probably allow best flexibility and
>>>>>>>> hopefully the usability will be also fine.
>>>>>>>>
>>>>>>>> Marek
>>>>>>>>
>>>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>>>> > Hello,
>>>>>>>> > we're testing Keycloak with Google as a social identity provider
>>>>>>>> and using
>>>>>>>> > the token exchange functionality to get access to the IDP access
>>>>>>>> token.
>>>>>>>> > I noticed that Google requires the access_type parameter to be
>>>>>>>> set to
>>>>>>>> > "offline" in the call to the authorization endpoint to release a
>>>>>>>> refresh
>>>>>>>> > token, but there is no easy way to do this in Keycloak;
>>>>>>>> configuring a
>>>>>>>> > generic OIDC identity provider allows me to configure access_type
>>>>>>>> as a
>>>>>>>> > forwarded parameter, but no such option exists using
>>>>>>>> GoogleIdentityProvider.
>>>>>>>> >
>>>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig and
>>>>>>>> overrides
>>>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>>>> values.
>>>>>>>> >
>>>>>>>> > Other options I considered include (b) changing the UI to allow to
>>>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>>>> (since it
>>>>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>>>>>> option to
>>>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>>>> parameter or
>>>>>>>> > (d) add a boolean configuration option to
>>>>>>>> GoogleIdentityProviderConfig to
>>>>>>>> > set "access_type" to "offline" if checked.
>>>>>>>> >
>>>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>>>> accepted?
>>>>>>>> > Cheers.
>>>>>>>> >
>>>>>>>> > *Francesco Degrassi*
>>>>>>>> > Tech Lead
>>>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>>>> > _______________________________________________
>>>>>>>> > keycloak-dev mailing list
>>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>>> > https://lists.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 francesco.degrassi at optionfactory.net  Wed Mar 13 08:35:03 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Wed, 13 Mar 2019 13:35:03 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAJgngAfzXzVuNfW0enk+ixiSoJy7ZjRRT93jRbXrkJTG0_kciQ@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
	<CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
	<CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>
	<CAJgngAfzXzVuNfW0enk+ixiSoJy7ZjRRT93jRbXrkJTG0_kciQ@mail.gmail.com>
Message-ID: <CAC-SaSwO2=13+nVhvXR9weub8fu0nZYMWZzX0omNWGMH0jMp=Q@mail.gmail.com>

I see your point, although in some cases the abstraction is leaky, e.g. in
the token exchange case, where the client knows there is Google behind KC
and relies on a refresh token being available even though KC doesn't
necessarily.
Maybe we could remap scope=offline to access_type=offline for Google, but
I'm not sure, it feels a workaround for Google doing their own thing.

Let me know your preference, I'm ok with removing the last option.
Cheers

Francesco

On Wed, 13 Mar 2019, 13:00 Stian Thorgersen, <sthorger at redhat.com> wrote:

>
>
> On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi <
> francesco.degrassi at optionfactory.net> wrote:
>
>> I understand.
>> Taking this into consideration, I'd propose to add a high-level config
>> option "offline access" to the Google Identity Provider configuration, a
>> dropdown with three possible values:
>> - never request offline access (which is the current behavior)
>> - always request offline access (which always adds the
>> access_type=offline to the authorization request to google)
>> - allow offline access to be requested by clients (with docs explaining
>> that clients can pass a access_type=offline parameter if they want refresh
>> tokens from google), which adds access_type as a forwarded parameter
>>
>
> I'm not convinced about the last option. When would you use that? Clients
> talk to KC, not Google. KC doesn't support access_type=offline so makes no
> sense that the client would use that.
>
>
>>
>> This should be easy to use and support all possible use cases; would you
>> support something of the sort?
>> Cheers
>>
>> *Francesco*
>>
>>
>> On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> End of the day we are trying to make Keycloak user friendly and having
>>> too many configuration options and tweaks doesn't help with that,
>>> especially config options like what is being proposed at the moment that
>>> requires users to know specific query parameters from Google.
>>>
>>> I'd rather see either this somehow automatically being figured out by
>>> Keycloak or a more high level config option being introduced. That is why
>>> I'm asking for details on your use-case and not just accepting a low level
>>> config option to be added without discussion.
>>>
>>> I don't think we will know if/when an offline token is needed
>>> automatically, so should rather look at adding an option to request offline
>>> token. With OIDC that's done through scope offline, but it seems Google has
>>> decided not to follow the spec, but rather do their own thing.
>>>
>>>
>>>
>>> On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
>>> francesco.degrassi at optionfactory.net> wrote:
>>>
>>>> Hello again, Stian.
>>>> Putting my specific use-case aside for a minute, do you see a specific
>>>> reason not to allow users to configure finer-grained OIDCIdentityProvider
>>>> options such as forwarded parameters for well-known, first-party supported,
>>>> OIDC compliant social login Identity Providers such as Google?
>>>>
>>>> *Francesco *
>>>>
>>>> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>
>>>>> We're logging users in through multiple identity providers configured
>>>>> on keycloak.
>>>>> Regardless of the idp used, the user can link their Google account (if
>>>>> they logged through a different idp) to have the application poll Google
>>>>> APIs periodically.
>>>>>
>>>>> Cheers
>>>>>
>>>>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Are you using offline tokens from Keycloak that are being exchanged
>>>>>> for offline tokens from Google? Or is it what I suspect that you have a
>>>>>> user logged-in through Google and you want to access something in Google
>>>>>> APIs while the user is logged-in?
>>>>>>
>>>>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>>
>>>>>>> I'm afraid I cannot agree, the key element is "unless you really
>>>>>>> need one".
>>>>>>> The use case for access_type=offline is just that, in case you need
>>>>>>> to refresh tokens offline (i.e. when the user is not at the browser).
>>>>>>> Forbidding a use case explicitly allowed and supported by google
>>>>>>> cannot be correct.
>>>>>>>
>>>>>>> I agree with Marek about the fact that allowing users to configure
>>>>>>> forwarded parameters is the simplest and more general solution, even though
>>>>>>> it is not the most user-frlendly, since people might not know they need to
>>>>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>>>>> documentation for Google Identity Provider.
>>>>>>>
>>>>>>> Should I open a Jira before submitting a PR?
>>>>>>> Cheers
>>>>>>>
>>>>>>> *Francesco*
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm not convinced about this approach for two reasons: it's not
>>>>>>>> very user-friendly and secondly it's not correct to request an offline
>>>>>>>> token unless you really need one.
>>>>>>>>
>>>>>>>> Google doesn't use refresh tokens for regular sessions, but rather
>>>>>>>> give you a fairly long expiration token. As it's lacking the refresh token
>>>>>>>> it means you need to refresh the token with a redirect. This can be done
>>>>>>>> with a hidden iframe. So the correct approach here is to have the app
>>>>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>>>>> tokens.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I already saw some request(s) in the past with regards to the
>>>>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>>>>> configuration as the OIDC Identity provider. I think that
>>>>>>>>> generally it
>>>>>>>>> will be nice to remove this limitation(s) and hence allow some
>>>>>>>>> custom
>>>>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>>>>
>>>>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>>>>> support
>>>>>>>>> forwarded parameters. This will probably allow best flexibility
>>>>>>>>> and
>>>>>>>>> hopefully the usability will be also fine.
>>>>>>>>>
>>>>>>>>> Marek
>>>>>>>>>
>>>>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>>>>> > Hello,
>>>>>>>>> > we're testing Keycloak with Google as a social identity provider
>>>>>>>>> and using
>>>>>>>>> > the token exchange functionality to get access to the IDP access
>>>>>>>>> token.
>>>>>>>>> > I noticed that Google requires the access_type parameter to be
>>>>>>>>> set to
>>>>>>>>> > "offline" in the call to the authorization endpoint to release a
>>>>>>>>> refresh
>>>>>>>>> > token, but there is no easy way to do this in Keycloak;
>>>>>>>>> configuring a
>>>>>>>>> > generic OIDC identity provider allows me to configure
>>>>>>>>> access_type as a
>>>>>>>>> > forwarded parameter, but no such option exists using
>>>>>>>>> GoogleIdentityProvider.
>>>>>>>>> >
>>>>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig
>>>>>>>>> and overrides
>>>>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>>>>> values.
>>>>>>>>> >
>>>>>>>>> > Other options I considered include (b) changing the UI to allow
>>>>>>>>> to
>>>>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>>>>> (since it
>>>>>>>>> > extends OidcIdentityProvider) or (c) add a boolean configuration
>>>>>>>>> option to
>>>>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>>>>> parameter or
>>>>>>>>> > (d) add a boolean configuration option to
>>>>>>>>> GoogleIdentityProviderConfig to
>>>>>>>>> > set "access_type" to "offline" if checked.
>>>>>>>>> >
>>>>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>>>>> accepted?
>>>>>>>>> > Cheers.
>>>>>>>>> >
>>>>>>>>> > *Francesco Degrassi*
>>>>>>>>> > Tech Lead
>>>>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>>>>> > _______________________________________________
>>>>>>>>> > keycloak-dev mailing list
>>>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>

From sthorger at redhat.com  Wed Mar 13 14:19:55 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Mar 2019 19:19:55 +0100
Subject: [keycloak-dev] Allow AdminEvents for custom resource types
In-Reply-To: <1dd9101d7a584ca3a8a1a9111f08ae87@BOSKGEXC02.boskg.local>
References: <b15b7ae09d5343318384c9b2bfa052a5@BOSKGEXC01.boskg.local>
	<CAJgngAf_76NRtyzhb6-ecBPwviMK0bijooB=PEgGqOWjOhV8Qg@mail.gmail.com>
	<d3ca8e635b09445d9f8a5a231863a602@BOSKGEXC01.boskg.local>
	<CAJgngAfc9PcC37Y4n7onxhzr-FMCjhCrCG=4Zrs=jbjy5RbT5A@mail.gmail.com>
	<1dd9101d7a584ca3a8a1a9111f08ae87@BOSKGEXC02.boskg.local>
Message-ID: <CAJgngAca8JpL2vbYDdJE_TpWhQZVVLKN9WURJNp6OukHSNN+Aw@mail.gmail.com>

Sorry for the late reply, but your PR works for me. It's a bit ugly, but I
can't think of a better way to do it. There's a test failing on the PR
though.

On Wed, 6 Mar 2019 at 12:18, L?sch, Sebastian <
Sebastian.Loesch at governikus.de> wrote:

> Hello devs,
>
>
>
> I developed an alternative approach:
> https://github.com/keycloak/keycloak/pull/5907
>
> It is backward compatible but open to new types of AdminEvent.
>
>
>
> Is this suitable for you?
>
>
>
> Best regards,
>
> Sebastian
>
>
>
>
>
> *Von:* Stian Thorgersen <sthorger at redhat.com>
> *Gesendet:* Mittwoch, 20. Februar 2019 15:31
> *An:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>
> *Cc:* keycloak-dev at lists.jboss.org
> *Betreff:* Re: [keycloak-dev] Allow AdminEvents for custom resource types
>
>
>
>
>
>
>
> On Wed, 20 Feb 2019 at 12:40, L?sch, Sebastian <
> Sebastian.Loesch at governikus.de> wrote:
>
> >We can't accept the PR as is due to it breaking backwards compatibility
> of the API.
>
> Ah, I overlooked the EventListenerProvider interface. That?s the point
> where AdminEvent becomes public API, right?
>
>
>
> It's not really public, but loads of people still use it. So yes, that's
> the main place.
>
>
>
>
>
> Our use-case is as follows: we need to support user substitutions. User
> Jane goes for vacation and nominates John as her substitute in a defined
> time period. John has all of Janes Roles and is able to perform her tasks.
>
> We implement this substitution as a keycloak extension. All substitutions
> must be tracked. We want to implement this using the AdminEvents.
>
>
>
> Do you have any other suggestions how we can accomplish tracking?
>
>
>
> Contribute it directly to Keycloak? Depends obviously on how much changes
> is needed, how it's designed, if can be properly documented and tested, etc.
>
>
>
> Alternatively, you could find an alternative approach that is backwards
> compatible. Perhaps ResourceType enum can be extended or somehow allowed to
> add custom types to it?
>
>
>
>
>
> Best regards,
>
> Sebastian
>
>
>
> *Von:* Stian Thorgersen <sthorger at redhat.com>
> *Gesendet:* Mittwoch, 20. Februar 2019 11:42
> *An:* L?sch, Sebastian <Sebastian.Loesch at governikus.de>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Betreff:* Re: [keycloak-dev] Allow AdminEvents for custom resource types
>
>
>
> We can't accept the PR as is due to it breaking backwards compatibility of
> the API.
>
>
>
> Can you elaborate on your use-case? I'm far from convinced we should
> support this level of customisation.
>
>
>
> On Wed, 20 Feb 2019, 05:32 L?sch, Sebastian, <
> Sebastian.Loesch at governikus.de> wrote:
>
> Hello devs,
>
> we implemented a custom resource type as an extension to keycloak.
> For traceability reasons we would like to track actions for this custom
> resource type via AdminEvents.
> Unfortunately the resource type is represented by the enum ResourceType.
> Therefore no AdminEvents for custom non standard resource types can be
> created.
> It would be nice if it is possible to specify the resource type as string
> value also.
>
> This is only a small change, because the resource type is only provided
> via enum but handled as string value internally.
> I provided a pull request for that enhancement:
> https://github.com/keycloak/keycloak/pull/5882
>
> May anybody have a look on that review?
>
> Best regards,
> Sebastian
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sthorger at redhat.com  Wed Mar 13 14:21:45 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Mar 2019 19:21:45 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAC-SaSwO2=13+nVhvXR9weub8fu0nZYMWZzX0omNWGMH0jMp=Q@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
	<CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
	<CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>
	<CAJgngAfzXzVuNfW0enk+ixiSoJy7ZjRRT93jRbXrkJTG0_kciQ@mail.gmail.com>
	<CAC-SaSwO2=13+nVhvXR9weub8fu0nZYMWZzX0omNWGMH0jMp=Q@mail.gmail.com>
Message-ID: <CAJgngAcwHOUrxibNhc7P_z_gO-3J3DH=JfeX-93Nvuj+S0xAbQ@mail.gmail.com>

I'd remove the last option and simply make it an "Request offline token:
ON/OFF".

If someone needs it in the future we can discuss it then

On Wed, 13 Mar 2019 at 13:35, Francesco Degrassi <
francesco.degrassi at optionfactory.net> wrote:

> I see your point, although in some cases the abstraction is leaky, e.g. in
> the token exchange case, where the client knows there is Google behind KC
> and relies on a refresh token being available even though KC doesn't
> necessarily.
> Maybe we could remap scope=offline to access_type=offline for Google, but
> I'm not sure, it feels a workaround for Google doing their own thing.
>
> Let me know your preference, I'm ok with removing the last option.
> Cheers
>
> Francesco
>
> On Wed, 13 Mar 2019, 13:00 Stian Thorgersen, <sthorger at redhat.com> wrote:
>
>>
>>
>> On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi <
>> francesco.degrassi at optionfactory.net> wrote:
>>
>>> I understand.
>>> Taking this into consideration, I'd propose to add a high-level config
>>> option "offline access" to the Google Identity Provider configuration, a
>>> dropdown with three possible values:
>>> - never request offline access (which is the current behavior)
>>> - always request offline access (which always adds the
>>> access_type=offline to the authorization request to google)
>>> - allow offline access to be requested by clients (with docs explaining
>>> that clients can pass a access_type=offline parameter if they want refresh
>>> tokens from google), which adds access_type as a forwarded parameter
>>>
>>
>> I'm not convinced about the last option. When would you use that? Clients
>> talk to KC, not Google. KC doesn't support access_type=offline so makes no
>> sense that the client would use that.
>>
>>
>>>
>>> This should be easy to use and support all possible use cases; would you
>>> support something of the sort?
>>> Cheers
>>>
>>> *Francesco*
>>>
>>>
>>> On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> End of the day we are trying to make Keycloak user friendly and having
>>>> too many configuration options and tweaks doesn't help with that,
>>>> especially config options like what is being proposed at the moment that
>>>> requires users to know specific query parameters from Google.
>>>>
>>>> I'd rather see either this somehow automatically being figured out by
>>>> Keycloak or a more high level config option being introduced. That is why
>>>> I'm asking for details on your use-case and not just accepting a low level
>>>> config option to be added without discussion.
>>>>
>>>> I don't think we will know if/when an offline token is needed
>>>> automatically, so should rather look at adding an option to request offline
>>>> token. With OIDC that's done through scope offline, but it seems Google has
>>>> decided not to follow the spec, but rather do their own thing.
>>>>
>>>>
>>>>
>>>> On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>
>>>>> Hello again, Stian.
>>>>> Putting my specific use-case aside for a minute, do you see a specific
>>>>> reason not to allow users to configure finer-grained OIDCIdentityProvider
>>>>> options such as forwarded parameters for well-known, first-party supported,
>>>>> OIDC compliant social login Identity Providers such as Google?
>>>>>
>>>>> *Francesco *
>>>>>
>>>>> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>
>>>>>> We're logging users in through multiple identity providers configured
>>>>>> on keycloak.
>>>>>> Regardless of the idp used, the user can link their Google account
>>>>>> (if they logged through a different idp) to have the application poll
>>>>>> Google APIs periodically.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Are you using offline tokens from Keycloak that are being exchanged
>>>>>>> for offline tokens from Google? Or is it what I suspect that you have a
>>>>>>> user logged-in through Google and you want to access something in Google
>>>>>>> APIs while the user is logged-in?
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>>>
>>>>>>>> I'm afraid I cannot agree, the key element is "unless you really
>>>>>>>> need one".
>>>>>>>> The use case for access_type=offline is just that, in case you need
>>>>>>>> to refresh tokens offline (i.e. when the user is not at the browser).
>>>>>>>> Forbidding a use case explicitly allowed and supported by google
>>>>>>>> cannot be correct.
>>>>>>>>
>>>>>>>> I agree with Marek about the fact that allowing users to configure
>>>>>>>> forwarded parameters is the simplest and more general solution, even though
>>>>>>>> it is not the most user-frlendly, since people might not know they need to
>>>>>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>>>>>> documentation for Google Identity Provider.
>>>>>>>>
>>>>>>>> Should I open a Jira before submitting a PR?
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> *Francesco*
>>>>>>>>
>>>>>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm not convinced about this approach for two reasons: it's not
>>>>>>>>> very user-friendly and secondly it's not correct to request an offline
>>>>>>>>> token unless you really need one.
>>>>>>>>>
>>>>>>>>> Google doesn't use refresh tokens for regular sessions, but rather
>>>>>>>>> give you a fairly long expiration token. As it's lacking the refresh token
>>>>>>>>> it means you need to refresh the token with a redirect. This can be done
>>>>>>>>> with a hidden iframe. So the correct approach here is to have the app
>>>>>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>>>>>> tokens.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I already saw some request(s) in the past with regards to the
>>>>>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>>>>>> configuration as the OIDC Identity provider. I think that
>>>>>>>>>> generally it
>>>>>>>>>> will be nice to remove this limitation(s) and hence allow some
>>>>>>>>>> custom
>>>>>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>>>>>
>>>>>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>>>>>> support
>>>>>>>>>> forwarded parameters. This will probably allow best flexibility
>>>>>>>>>> and
>>>>>>>>>> hopefully the usability will be also fine.
>>>>>>>>>>
>>>>>>>>>> Marek
>>>>>>>>>>
>>>>>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>>>>>> > Hello,
>>>>>>>>>> > we're testing Keycloak with Google as a social identity
>>>>>>>>>> provider and using
>>>>>>>>>> > the token exchange functionality to get access to the IDP
>>>>>>>>>> access token.
>>>>>>>>>> > I noticed that Google requires the access_type parameter to be
>>>>>>>>>> set to
>>>>>>>>>> > "offline" in the call to the authorization endpoint to release
>>>>>>>>>> a refresh
>>>>>>>>>> > token, but there is no easy way to do this in Keycloak;
>>>>>>>>>> configuring a
>>>>>>>>>> > generic OIDC identity provider allows me to configure
>>>>>>>>>> access_type as a
>>>>>>>>>> > forwarded parameter, but no such option exists using
>>>>>>>>>> GoogleIdentityProvider.
>>>>>>>>>> >
>>>>>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig
>>>>>>>>>> and overrides
>>>>>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>>>>>> values.
>>>>>>>>>> >
>>>>>>>>>> > Other options I considered include (b) changing the UI to allow
>>>>>>>>>> to
>>>>>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>>>>>> (since it
>>>>>>>>>> > extends OidcIdentityProvider) or (c) add a boolean
>>>>>>>>>> configuration option to
>>>>>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>>>>>> parameter or
>>>>>>>>>> > (d) add a boolean configuration option to
>>>>>>>>>> GoogleIdentityProviderConfig to
>>>>>>>>>> > set "access_type" to "offline" if checked.
>>>>>>>>>> >
>>>>>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>>>>>> accepted?
>>>>>>>>>> > Cheers.
>>>>>>>>>> >
>>>>>>>>>> > *Francesco Degrassi*
>>>>>>>>>> > Tech Lead
>>>>>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > keycloak-dev mailing list
>>>>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>>>>> > https://lists.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 francesco.degrassi at optionfactory.net  Wed Mar 13 14:24:10 2019
From: francesco.degrassi at optionfactory.net (Francesco Degrassi)
Date: Wed, 13 Mar 2019 19:24:10 +0100
Subject: [keycloak-dev] Allow access_type parameter to be sent to Google
 Identity Provider
In-Reply-To: <CAJgngAcwHOUrxibNhc7P_z_gO-3J3DH=JfeX-93Nvuj+S0xAbQ@mail.gmail.com>
References: <CAC-SaSyCJ1KfS_oVT+20w8DtBqLmmd2zrpjbtatT9f=DsQUf9g@mail.gmail.com>
	<aec8459b-fe03-4ff1-7648-29752dc80b0c@redhat.com>
	<CAJgngAdOG5m-M+Vi9h2MWJbwCLpVV-R8ynyGxrNxTJtoRoiMjg@mail.gmail.com>
	<CAC-SaSxd6LAEcBA1GE+wkAWF8Y8c490CzbmBnNmvHe9G80bBaQ@mail.gmail.com>
	<CAJgngAeqVqVoH9AKuDmTsVZhpg09M5z4kKNTOC6k725CM=253A@mail.gmail.com>
	<CAC-SaSyFg0jc9JBE1fJnzN0iFxUbWdJKT02zF-23UaT8XOq-VA@mail.gmail.com>
	<CAC-SaSxsuAY-Kcvb4YMto2T_zgOEDXmWpcf9kU2m5X1086vrOQ@mail.gmail.com>
	<CAJgngAdPf5s+KsAWkTEVrk8U-OPw1oSzfoJmy1+Ms0RUYfKgYw@mail.gmail.com>
	<CAC-SaSxCf3B0P9SYg2_FvU1GtRq_zF9WLXkVD97YzCY0VSn4MA@mail.gmail.com>
	<CAJgngAfzXzVuNfW0enk+ixiSoJy7ZjRRT93jRbXrkJTG0_kciQ@mail.gmail.com>
	<CAC-SaSwO2=13+nVhvXR9weub8fu0nZYMWZzX0omNWGMH0jMp=Q@mail.gmail.com>
	<CAJgngAcwHOUrxibNhc7P_z_gO-3J3DH=JfeX-93Nvuj+S0xAbQ@mail.gmail.com>
Message-ID: <CAC-SaSzVho6uFatVbjE6SjWG8kg8RXZsLfYbzpbcAWLWH4HzsQ@mail.gmail.com>

Ok, thanks.
I'll open a Jira and submit a PR to this effect ASAP.

On Wed, 13 Mar 2019, 19:21 Stian Thorgersen, <sthorger at redhat.com> wrote:

> I'd remove the last option and simply make it an "Request offline token:
> ON/OFF".
>
> If someone needs it in the future we can discuss it then
>
> On Wed, 13 Mar 2019 at 13:35, Francesco Degrassi <
> francesco.degrassi at optionfactory.net> wrote:
>
>> I see your point, although in some cases the abstraction is leaky, e.g.
>> in the token exchange case, where the client knows there is Google behind
>> KC and relies on a refresh token being available even though KC doesn't
>> necessarily.
>> Maybe we could remap scope=offline to access_type=offline for Google, but
>> I'm not sure, it feels a workaround for Google doing their own thing.
>>
>> Let me know your preference, I'm ok with removing the last option.
>> Cheers
>>
>> Francesco
>>
>> On Wed, 13 Mar 2019, 13:00 Stian Thorgersen, <sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, 13 Mar 2019 at 10:39, Francesco Degrassi <
>>> francesco.degrassi at optionfactory.net> wrote:
>>>
>>>> I understand.
>>>> Taking this into consideration, I'd propose to add a high-level config
>>>> option "offline access" to the Google Identity Provider configuration, a
>>>> dropdown with three possible values:
>>>> - never request offline access (which is the current behavior)
>>>> - always request offline access (which always adds the
>>>> access_type=offline to the authorization request to google)
>>>> - allow offline access to be requested by clients (with docs explaining
>>>> that clients can pass a access_type=offline parameter if they want refresh
>>>> tokens from google), which adds access_type as a forwarded parameter
>>>>
>>>
>>> I'm not convinced about the last option. When would you use that?
>>> Clients talk to KC, not Google. KC doesn't support access_type=offline so
>>> makes no sense that the client would use that.
>>>
>>>
>>>>
>>>> This should be easy to use and support all possible use cases; would
>>>> you support something of the sort?
>>>> Cheers
>>>>
>>>> *Francesco*
>>>>
>>>>
>>>> On Wed, 13 Mar 2019 at 10:14, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> End of the day we are trying to make Keycloak user friendly and having
>>>>> too many configuration options and tweaks doesn't help with that,
>>>>> especially config options like what is being proposed at the moment that
>>>>> requires users to know specific query parameters from Google.
>>>>>
>>>>> I'd rather see either this somehow automatically being figured out by
>>>>> Keycloak or a more high level config option being introduced. That is why
>>>>> I'm asking for details on your use-case and not just accepting a low level
>>>>> config option to be added without discussion.
>>>>>
>>>>> I don't think we will know if/when an offline token is needed
>>>>> automatically, so should rather look at adding an option to request offline
>>>>> token. With OIDC that's done through scope offline, but it seems Google has
>>>>> decided not to follow the spec, but rather do their own thing.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 12 Mar 2019 at 21:26, Francesco Degrassi <
>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>
>>>>>> Hello again, Stian.
>>>>>> Putting my specific use-case aside for a minute, do you see a
>>>>>> specific reason not to allow users to configure finer-grained
>>>>>> OIDCIdentityProvider options such as forwarded parameters for well-known,
>>>>>> first-party supported, OIDC compliant social login Identity Providers such
>>>>>> as Google?
>>>>>>
>>>>>> *Francesco *
>>>>>>
>>>>>> On Tue, 12 Mar 2019 at 19:20, Francesco Degrassi <
>>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>>
>>>>>>> We're logging users in through multiple identity providers
>>>>>>> configured on keycloak.
>>>>>>> Regardless of the idp used, the user can link their Google account
>>>>>>> (if they logged through a different idp) to have the application poll
>>>>>>> Google APIs periodically.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019, 18:54 Stian Thorgersen, <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Are you using offline tokens from Keycloak that are being exchanged
>>>>>>>> for offline tokens from Google? Or is it what I suspect that you have a
>>>>>>>> user logged-in through Google and you want to access something in Google
>>>>>>>> APIs while the user is logged-in?
>>>>>>>>
>>>>>>>> On Tue, 12 Mar 2019 at 15:27, Francesco Degrassi <
>>>>>>>> francesco.degrassi at optionfactory.net> wrote:
>>>>>>>>
>>>>>>>>> I'm afraid I cannot agree, the key element is "unless you really
>>>>>>>>> need one".
>>>>>>>>> The use case for access_type=offline is just that, in case you
>>>>>>>>> need to refresh tokens offline (i.e. when the user is not at the browser).
>>>>>>>>> Forbidding a use case explicitly allowed and supported by google
>>>>>>>>> cannot be correct.
>>>>>>>>>
>>>>>>>>> I agree with Marek about the fact that allowing users to configure
>>>>>>>>> forwarded parameters is the simplest and more general solution, even though
>>>>>>>>> it is not the most user-frlendly, since people might not know they need to
>>>>>>>>> add access_type as a forwarded parameter. Maybe it can be mitigated through
>>>>>>>>> documentation for Google Identity Provider.
>>>>>>>>>
>>>>>>>>> Should I open a Jira before submitting a PR?
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>> *Francesco*
>>>>>>>>>
>>>>>>>>> On Tue, 12 Mar 2019 at 15:09, Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> I'm not convinced about this approach for two reasons: it's not
>>>>>>>>>> very user-friendly and secondly it's not correct to request an offline
>>>>>>>>>> token unless you really need one.
>>>>>>>>>>
>>>>>>>>>> Google doesn't use refresh tokens for regular sessions, but
>>>>>>>>>> rather give you a fairly long expiration token. As it's lacking the refresh
>>>>>>>>>> token it means you need to refresh the token with a redirect. This can be
>>>>>>>>>> done with a hidden iframe. So the correct approach here is to have the app
>>>>>>>>>> refresh the token by re-auth to KC  with a redirect (which can be in a
>>>>>>>>>> hidden iframe). This will do it in a proper way without using offline
>>>>>>>>>> tokens.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, 12 Mar 2019 at 14:32, Marek Posolda <mposolda at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I already saw some request(s) in the past with regards to the
>>>>>>>>>>> GoogleIdentityProvider not provide same level of fine-grained
>>>>>>>>>>> configuration as the OIDC Identity provider. I think that
>>>>>>>>>>> generally it
>>>>>>>>>>> will be nice to remove this limitation(s) and hence allow some
>>>>>>>>>>> custom
>>>>>>>>>>> configurations to be done on the GoogleIdentityProvider as well.
>>>>>>>>>>>
>>>>>>>>>>> So IMO the best would be the option (b) - just add the option to
>>>>>>>>>>> support
>>>>>>>>>>> forwarded parameters. This will probably allow best flexibility
>>>>>>>>>>> and
>>>>>>>>>>> hopefully the usability will be also fine.
>>>>>>>>>>>
>>>>>>>>>>> Marek
>>>>>>>>>>>
>>>>>>>>>>> On 12/03/2019 11:19, Francesco Degrassi wrote:
>>>>>>>>>>> > Hello,
>>>>>>>>>>> > we're testing Keycloak with Google as a social identity
>>>>>>>>>>> provider and using
>>>>>>>>>>> > the token exchange functionality to get access to the IDP
>>>>>>>>>>> access token.
>>>>>>>>>>> > I noticed that Google requires the access_type parameter to be
>>>>>>>>>>> set to
>>>>>>>>>>> > "offline" in the call to the authorization endpoint to release
>>>>>>>>>>> a refresh
>>>>>>>>>>> > token, but there is no easy way to do this in Keycloak;
>>>>>>>>>>> configuring a
>>>>>>>>>>> > generic OIDC identity provider allows me to configure
>>>>>>>>>>> access_type as a
>>>>>>>>>>> > forwarded parameter, but no such option exists using
>>>>>>>>>>> GoogleIdentityProvider.
>>>>>>>>>>> >
>>>>>>>>>>> > I have a patch that (a) modifies GoogleIdentityProviderConfig
>>>>>>>>>>> and overrides
>>>>>>>>>>> > getForwardedParameters() to add "access_type" to the returned
>>>>>>>>>>> values.
>>>>>>>>>>> >
>>>>>>>>>>> > Other options I considered include (b) changing the UI to
>>>>>>>>>>> allow to
>>>>>>>>>>> > configure the forwareded parameters for GoogleIdentityProvider
>>>>>>>>>>> (since it
>>>>>>>>>>> > extends OidcIdentityProvider) or (c) add a boolean
>>>>>>>>>>> configuration option to
>>>>>>>>>>> > GoogleIdentityProviderConfig to allow/disallow forwarding the
>>>>>>>>>>> parameter or
>>>>>>>>>>> > (d) add a boolean configuration option to
>>>>>>>>>>> GoogleIdentityProviderConfig to
>>>>>>>>>>> > set "access_type" to "offline" if checked.
>>>>>>>>>>> >
>>>>>>>>>>> > Which would be the preferred route? Would a pull request be
>>>>>>>>>>> accepted?
>>>>>>>>>>> > Cheers.
>>>>>>>>>>> >
>>>>>>>>>>> > *Francesco Degrassi*
>>>>>>>>>>> > Tech Lead
>>>>>>>>>>> > +39 329 4128 422 <+39+329+4128+422>
>>>>>>>>>>> > *OptionFactory <http://www.optionfactory.net/>*
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > keycloak-dev mailing list
>>>>>>>>>>> > keycloak-dev at lists.jboss.org
>>>>>>>>>>> > https://lists.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 tkyjovsk at redhat.com  Wed Mar 13 17:49:49 2019
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Wed, 13 Mar 2019 17:49:49 -0400 (EDT)
Subject: [keycloak-dev] Provisioning of Keycloak deployments
In-Reply-To: <763cb40f-3320-7825-9d40-d50c0b9a95db@redhat.com>
References: <1269049447.7745451.1552085945195.JavaMail.zimbra@redhat.com>
	<763cb40f-3320-7825-9d40-d50c0b9a95db@redhat.com>
Message-ID: <1178433279.8445206.1552513789648.JavaMail.zimbra@redhat.com>

Thanks for sharing, John. This is good to know.

I will keep an eye on the project and have a closer look once we get to the bare-metal provisioning stuff for our performace testing.


----- Original Message -----
> On 3/8/19 5:59 PM, Tomas Kyjovsky wrote:
> > Looking at the feedback in the questionare, there are several
> > requests to make provisioning and configuration of KC deployments
> > easier.
> 
> > I was also thinking about this in relation to our testsuite for a
>  > while ...
> 
> FYI we in the middle of developing Ansible tools to deploy and
> configure Keycloak. This effort is aimed at testing single sign-on
> federation in OpenStack in a CI environment. There is an opportunity
> here for collaboration.
> 
> Nathan Kinder recently wrote this Ansible role to deploy the Keycloak
> server, I expect it will be submitted to upstream Ansible once it has a
> bit more soak time.
> 
> https://github.com/nkinder/ansible-keycloak
> 
> I'm in the process of using this in conjunction with the existing
> ansible keycloak_client and some new Ansible roles to establish
> federation in OpenStack. While it is true our work targets OpenStack
> there is no reason why the components cannot form the basis of a toolbox
> for a host of other deployment and testng needs.

Interesting, I didn't even notice this module was added to Ansible. Thanks for mentioning it.

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


Tomas Kyjovsky

From alistair.doswald at elca.ch  Thu Mar 14 09:02:24 2019
From: alistair.doswald at elca.ch (Doswald Alistair)
Date: Thu, 14 Mar 2019 13:02:24 +0000
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
 implementing JIRAs
In-Reply-To: <CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>,
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
Message-ID: <111481de90e245cabb85e75fa4f72c70@elca.ch>

This is OK for me. I propose starting with initial proposals for the fundamentals in this email, and once there's an agreement on those, separating the discussion between the two JIRAs to refine the concepts for each one. Once the work to be done is clearer, it can be supplemented with screen mockups and/or prototypes.





1) Scope of the modifications



- For JIRA KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>, I believe that the description in the JIRA is not general enough to cover the description in web-authn-two-factor.md<https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>. Modifications to the authentication flows should support single factor, as well as 2nd factor and allow both authentication factor levels to select the alternative types of authenticator to be used. This allows a single factor authentication to use for example a FIDO2 dongle for passwordless authentication, or even let the user choose between the dongle and a password during the login.  Modifications for this JIRA include: changes to the authentication logic, changes to the authentication part of the admin console, changes to the authentication screens that the user sees during login, changes to the REST API, and possibly some changes to the database.



- For JIRA KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>, changes are to the "users > credentials" part of the administration console and to the REST API.





2) Design proposal for KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>



a) Authentication logic



The current authentication flow system should be kept, but perhaps simplified. For a start I think that actual authenticators categories - that is elements that provide identity (e.g. password, cookie, kerberos, otp, fido, ...) - should be separate from other executions like "reset password".



Thus, instead of directly adding "cookie" or "password" as alternatives in the authentication flow, the user can add the execution "authentication factor", and under authentication factor he can add only the valid authenticator categories. Each of the authenticator categories under the authentication factor are considered valid alternatives, and are evaluated in order. The authentication stops being automatically evaluated at the first authenticator that requires user input (alternative: all non-user input authenticators are evaluated before the first user-input authenticator).



Adding a 2nd "authentication factor" execution sets the 2nd factor, and it must then have authenticators assigned. To have an authenticator category be valid for both authentication factors it must be set under both 1st and 2nd authentication factor. For example, kerberos could be set for both 1st and 2nd factor, which would mean that the user skips both factors if he's registered with kerberos, but it could also be just set for the first factor, in which case he'd still have to input the 2nd factor. To handle optional 2nd factors there could either be a "optional authentication factor type" or have an "optional" flag in the options of the "authentication factor".



Potentially, this system could also allow a company that's really security conscientious/paranoiac to set N factors.



Authentication factors are treated as a bloc in the evaluation of alternatives. That is, if in a flow there's "Identity provider redirector", "authentication factor 1", "authentication factor 2", entering the authentication factor 1 flow will automatically cause "authentication factor 2" to be executed after.



To make things perhaps a little more clear, the current default "Browser" authentication would become for example:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2) [OPTIONAL]

  |- Cookie

  |- Kerberos

  |- OTP Form



And if we wanted to have an mandatory 2nd factor, with either OTP or a FIDO2 configured:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2)

  |- Cookie

  |- Kerberos

  |- OTP Form

  |- FIDO-2



Potentially we could also introduce another type of authentication execution, we could call it "Authenticated on", to simplify the authenticators that bypass the authentication factors. We could then have:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authenticated on

  |- Cookie

  |- Kerberos

Authentication factor (1)

  |- Username Password Form

Authentication factor (2)

  |- OTP Form

  |- FIDO-2



b) Authentication section in the admin console



The schema described in a) would be implemented in the Authentication > flows. Bindings and Required Actions don't need any change I think. For policies I believe the password policy for the realm should remain, but the OTP policy should disappear, as a user could have several alternative OTP devices with different settings. As such, the information about the OTP settings should probably move to information associated with the credential.



c) Authentication screens for the user



When the user logs in, unless he has something like a cookie he will see by default the first configuration interface configured in the current Authentication factor. If there are many different factors configured, he can access a list of any valid authenticator to use. If the user fails with the selected authenticator, he may choose another configured authenticator to validate the step.



d) REST API



There's no major change here, aside from updating the scheme to support the separation between authenticator categories and executions, and adding instructions to edit which authenticator categories are assigned to an authentication factor.



e) database modifications



Authenticator categories could be separated from executions either by having a new dedicated table, or by introducing a field in the authentication_execution table





3) Design proposal for KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>



a) Changes to the users > Credential menu



Instead of manage Password we have "manage credentials", with a list of credentials for a user. The credentials grouped by type, and should indicate by which authentication factor they are valid for (1st factor, 2nd factor, unconfigured). The administrator should be able to edit / remove a credential.



- For editing the administrator should be able to visualise the data of the credential (except the secret and the salt) and edit metadata about a device. Data would be any data in the fields of the credential that describe immutable data about the credential, and metadata would be for example label that a user can see and edit to name his device and a label that only the administrator could see and edit. The administrator (and user) should be able to set a "preferred credential" for each authentication factor level, which will override the factor shown by default during the login.



- For deleting, I think that this should be linked to the authentication factors and authenticator categories of the realm, for example:

   + For a realm with a single factor configured of types password and FIDO2, the credentials can be removed until ONE remains, and that last one cannot be removed.

   + For a realm with a two factors configured, the first with password and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very good example from a security point of view), then it must be impossible to remove the last credential for the first factor, and to remove the last credential for the second factor.



A note for passwords: Unlike other credentials I don't think that there should be more than one password that can be configured. Also, among its edition option it should be possible to reset (temporarily or not) as is currently the case.



If the administrator and user can remove credentials, I do not know if the possibility to disable credentials is still useful. I don't see any problems with the feature either though, so if it?s still deemed useful it would keep its current behaviour.



b) Modifications to the REST API



Currently there's no way to get credentials with the REST API. This should change with these modifications to reflect the new options for the administrator. The API should function in the same manner as the admin console: Credentials can be exposed (except for secret and hash values), the metadata edited and the credentials deleted with the same restrictions as described in section 3a



c) Database modifications



I do not believe that this modification entails any database modifications. The current system with credential and credential attributes should be sufficient for the handling of multiple authenticators.




That's it. Comments, questions and criticism are all welcome.

________________________________
From: Stian Thorgersen <sthorger at redhat.com>
Sent: 08 March 2019 13:17
To: Doswald Alistair
Cc: keycloak-dev
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs

No one is working on the admin part at the moment, so contributions here would be very welcome. It's not a straightforward task though and would need a fair bit of design/prototyping/discussions to get this right.

On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
Hello,


I've been following the thread about the implementation of WebAuthn in Keycloak, and saw that there are some related JIRAs in the following design document https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md.


Is anyone  already working on JIRAs https://issues.jboss.org/browse/KEYCLOAK-9693 and https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd factor authenticators? If not, with my colleagues we could implement them relatively quickly as we have use cases for these functionalities.


Best regards,


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

From sthorger at redhat.com  Thu Mar 14 10:44:34 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Mar 2019 15:44:34 +0100
Subject: [keycloak-dev] Implementation of Front-Channel Logout for
 OpenID Connect clients
In-Reply-To: <CAJgngAeroemi9y4nSs-KQgWuRL+B8k97CXdQqRZ5YMhfSKs5=g@mail.gmail.com>
References: <CAO0=Nf6NOCZ-i0hK7GruwvH5SrZVj1OwThtaMoNBzqzRe3Ux-A@mail.gmail.com>
	<4ed71ae6-265f-4f95-d97d-e1ab66e9f1e6@redhat.com>
	<CAK-7U1gbAv3Vag0soYiAtuPxw7Jnn43imvjFKBqOsSiHosrqdQ@mail.gmail.com>
	<CAO0=Nf4GwRAOAkRhT9-71U+2W8StL=kzOFem85Y+7rWXEYmswA@mail.gmail.com>
	<CAJgngAeroemi9y4nSs-KQgWuRL+B8k97CXdQqRZ5YMhfSKs5=g@mail.gmail.com>
Message-ID: <CAJgngAf+PLbmwHEKF4Ca9zFLy7mRx=HTtiOFeU5PZYoy00af_A@mail.gmail.com>

Got confirmation from the OIDC group that session management and both
logout specifications are on track to be made finalised soon.

So - Contributions welcome :)

On Tue, 12 Mar 2019 at 18:57, Stian Thorgersen <sthorger at redhat.com> wrote:

> I have my worries about this spec. It was proposed back in Jan 2017 and is
> still in draft state. It seems to be abandoned.
>
> Before adding support for this spec we should look for alternatives and
> check what the status is of the spec and why nothing is happening with it.
>
> On Tue, 12 Mar 2019 at 13:16, Diego Liberalquino <diegoliber at gmail.com>
> wrote:
>
>> Hi,
>>
>> I want to make the contribution, yes. I'm very interested that this
>> feature
>> gets implemented on Keycloak. It'll take some time though, I'm still
>> familiarizing myself with Keycloak's test suite, so I want to make sure my
>> contribution doesn't break anything.
>>
>> I've read this discussion about iframe based logout on SAML and agree on
>> 100% percent that the iframe-based approach is the best solution for this
>> problem and I was already getting inspiration from the SAML
>> implementation.
>> OIDC FrontChannel Spec also expects the use of iframes [1].
>>
>> Thanks for the follow up!
>>
>> [1] https://openid.net/specs/openid-connect-frontchannel-1_0.html
>>
>> Diego
>>
>> On Tue, Mar 12, 2019 at 8:36 AM Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>> > Link to the discussion was broken:
>> > [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.html
>> >
>> > Am Di., 12. M?rz 2019 um 12:30 Uhr schrieb Marek Posolda <
>> > mposolda at redhat.com>:
>> >
>> >> Hi,
>> >>
>> >> there is this JIRA opened already [1] . We have it planned, so we want
>> >> to look at it, but lack of other things caused that this wasn't
>> >> prioritized in last years... Do you want to contribute the feature?
>> >>
>> >> BTV. There is this old discussion when we discuss the "iframes" to be
>> >> used for frontchannel logout rather than redirect based approach [2].
>> >> You can see some more context by going through this old thread. I think
>> >> that we already support iframe based frontchannel logout for SAML
>> >> specification, or at least it is already available in Hynek's branch as
>> >> mentioned in the comment of this JIRA [3]. So hopefully OIDC can re-use
>> >> some parts of it.
>> >>
>> >> Let us know if you're interested in contributing this.
>> >>
>> >> [1] https://issues.jboss.org/browse/KEYCLOAK-2939
>> >> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009260.htm
>> >> [3] https://issues.jboss.org/browse/KEYCLOAK-5449
>> >>
>> >> Marek
>> >>
>> >> On 10/03/2019 04:03, Diego Liberalquino wrote:
>> >> > Hello,
>> >> >
>> >> > A thing that bothers me on Keycloak is the lack of implementation of
>> >> > Front-Channel Logout for OpenID Clients. Is there any technical
>> reason
>> >> for
>> >> > this or is just awaiting a community contribution? I mean, the spec
>> is
>> >> > supported for SAML clients, and it also works for external OIDC
>> >> providers.
>> >> >
>> >> > Best regards,
>> >> > Diego Liberalquino
>> >> > _______________________________________________
>> >> > keycloak-dev mailing list
>> >> > keycloak-dev at lists.jboss.org
>> >> > https://lists.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 sthorger at redhat.com  Thu Mar 14 10:47:28 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Mar 2019 15:47:28 +0100
Subject: [keycloak-dev] OIDC session management,
 front/back channel logout specifications soon to be finalised
Message-ID: <CAJgngAeOtnsHcEvX6hoWTC9i+1JNMrr1Acio43goBwv9tVH69Q@mail.gmail.com>

FIY all 3 specifications in $sub are on track to be finalised soon.

Session management - we're mostly here I believe, but need to run
conformance tests

Front-channel - we don't have this, so contributions would be welcome

Back-channel - we have something similar, but doesn't follow the spec. So
we need to fix this. Could introduce a new endpoint that is spec compliant
and deprecate the old. Or we morph the old endpoint into the new, which may
be more awkward for users, so my vote goes to new compliant endpoint.

From yuichi.nakamura.fe at hitachi.com  Fri Mar 15 03:13:11 2019
From: yuichi.nakamura.fe at hitachi.com (=?utf-8?B?5Lit5p2R6ZuE5LiAIC8gTkFLQU1VUkHvvIxZVVVJQ0hJ?=)
Date: Fri, 15 Mar 2019 07:13:11 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
Message-ID: <TY2PR01MB4540B5A73CE0F24E85DD3FABC9440@TY2PR01MB4540.jpnprd01.prod.outlook.com>

Hi, 

We?ve uploaded the initial prototype of webauthn authenticator below:  
https://github.com/webauthn4j/keycloak-webauthn-authenticator

Feedback is welcomed.

From: Stian Thorgersen <sthorger at redhat.com> 
Sent: Thursday, February 28, 2019 6:53 PM
To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

That's great, thanks.

Do you have an idea on roughly when you can have a prototype ready?

On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com> wrote:
Hi,

My team has begun to help webauthn4j project, 
and is going to develop prototype of authenticator for keycloak.
We'd like to take this.

Regards,
Yuichi Nakamura
Hitachi, Ltd.

-----Original Message-----
From: mailto:keycloak-dev-bounces at lists.jboss.org <mailto:keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j extension

A while back I created an experimental extension to Keycloak for FIDO U2F.
It would be great if someone could adapt this to WebAuthn by leveraging webauthn4j library [1].

Any takers? It shouldn't be hard ;)

[1] https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
_______________________________________________
keycloak-dev mailing list
mailto:keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev


From sthorger at redhat.com  Fri Mar 15 04:25:17 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 15 Mar 2019 09:25:17 +0100
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
	implementing JIRAs
In-Reply-To: <111481de90e245cabb85e75fa4f72c70@elca.ch>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
	<111481de90e245cabb85e75fa4f72c70@elca.ch>
Message-ID: <CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>

* Would be worth moving this to a design proposal on
https://github.com/keycloak/keycloak-community/tree/master/design. Would be
easier to work collectively on a design proposal there than to have an
endless thread on a ML ;). I'd also be open to join you on a call to have a
discussion "face to face"

* I was thinking to limit to two factor for now, but you're probably right
here with regards to consider the bigger picture now as it may be difficult
to get it right otherwise

* Need to consider how this fits into step-up authentication

* Admins should be able to select level of authentication required, but
users should be able to choose from available options

* Users should be able to select from available mechanisms when
configuring. Users should be able to set their own default. This means the
account console/rest needs metadata to discover available mechanisms. I
wonder if there's a need for something outside of flows and authenticators
to capture metadata about supported credential types which is used by
account and admin consoles to manage credentials.

* I was aiming a simpler setup where admin doesn't need to create custom
flow unless they want to add custom authenticators. That means
authenticators should be enabled/disabled in the flow rather than
added/removed

Some more comments inline below

On Thu, 14 Mar 2019 at 14:02, Doswald Alistair <alistair.doswald at elca.ch>
wrote:

> This is OK for me. I propose starting with initial proposals for the
> fundamentals in this email, and once there's an agreement on those,
> separating the discussion between the two JIRAs to refine the concepts for
> each one. Once the work to be done is clearer, it can be supplemented with
> screen mockups and/or prototypes.
>
>
>
>
>
> 1) Scope of the modifications
>
>
>
> - For JIRA KEYCLOAK-9693 <https://issues.jboss.org/browse/KEYCLOAK-9693>,
> I believe that the description in the JIRA is not general enough to cover
> the description in web-authn-two-factor.md
> <https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>
> . Modifications to the authentication flows should support single factor,
> as well as 2nd factor and allow both authentication factor levels to select
> the alternative types of authenticator to be used. This allows a single
> factor authentication to use for example a FIDO2 dongle for passwordless
> authentication, or even let the user choose between the dongle and a
> password during the login.  Modifications for this JIRA include: changes to
> the authentication logic, changes to the authentication part of the admin
> console, changes to the authentication screens that the user sees during
> login, changes to the REST API, and possibly some changes to the database.
>
>
In the first round we are focusing on two factor. Follow-up later is
passwordless flows for web-authn. Passwordless is more tricky as it
requires identity first login flow, ability for users to somehow define how
they authenticate, rather than just what the second factor is, ability for
admins to define authentication optoins rather than just two factor options.

As I mentioned above though it is probably all to linked to consider only
one at the design phase. So perhaps we need to work together on a design
proposal that will include everything including step-up authentication.


>
>
> - For JIRA KEYCLOAK-9694 <https://issues.jboss.org/browse/KEYCLOAK-9694>,
> changes are to the "users > credentials" part of the administration console
> and to the REST API.
>
>
>
>
>
> 2) Design proposal for KEYCLOAK-9693
> <https://issues.jboss.org/browse/KEYCLOAK-9693>
>
>
>
> a) Authentication logic
>
>
>
> The current authentication flow system should be kept, but perhaps
> simplified. For a start I think that actual authenticators categories -
> that is elements that provide identity (e.g. password, cookie, kerberos,
> otp, fido, ...) - should be separate from other executions like "reset
> password".
>
>
>
> Thus, instead of directly adding "cookie" or "password" as alternatives in
> the authentication flow, the user can add the execution "authentication
> factor", and under authentication factor he can add only the valid
> authenticator categories. Each of the authenticator categories under the
> authentication factor are considered valid alternatives, and are evaluated
> in order. The authentication stops being automatically evaluated at the
> first authenticator that requires user input (alternative: all non-user
> input authenticators are evaluated before the first user-input
> authenticator).
>

>
> Adding a 2nd "authentication factor" execution sets the 2nd factor, and it
> must then have authenticators assigned. To have an authenticator category
> be valid for both authentication factors it must be set under both 1st and
> 2nd authentication factor. For example, kerberos could be set for both 1st
> and 2nd factor, which would mean that the user skips both factors if he's
> registered with kerberos, but it could also be just set for the first
> factor, in which case he'd still have to input the 2nd factor. To handle
> optional 2nd factors there could either be a "optional authentication
> factor type" or have an "optional" flag in the options of the
> "authentication factor".
>
>
>
> Potentially, this system could also allow a company that's really security
> conscientious/paranoiac to set N factors.
>
>
>
> Authentication factors are treated as a bloc in the evaluation of
> alternatives. That is, if in a flow there's "Identity provider redirector",
> "authentication factor 1", "authentication factor 2", entering the
> authentication factor 1 flow will automatically cause "authentication
> factor 2" to be executed after.
>
>
>
> To make things perhaps a little more clear, the current default "Browser"
> authentication would become for example:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2) [OPTIONAL]
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>
>
> And if we wanted to have an mandatory 2nd factor, with either OTP or a
> FIDO2 configured:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>   |- FIDO-2
>
>
>
> Potentially we could also introduce another type of authentication
> execution, we could call it "Authenticated on", to simplify the
> authenticators that bypass the authentication factors. We could then have:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authenticated on
>
>   |- Cookie
>
>   |- Kerberos
>
> Authentication factor (1)
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- OTP Form
>
>   |- FIDO-2
>

I like this in general. Devil is in the detail here though and need to
think about this some more, especially how it fits into
step-up-authentication.


>
>
> b) Authentication section in the admin console
>
>
>
> The schema described in a) would be implemented in the Authentication >
> flows. Bindings and Required Actions don't need any change I think. For
> policies I believe the password policy for the realm should remain, but the
> OTP policy should disappear, as a user could have several alternative OTP
> devices with different settings. As such, the information about the OTP
> settings should probably move to information associated with the credential.
>

+1 I also think this is limited to the flow itself. Bear in mind I want to
have a built-in flow that can be configured rather than requiring creating
new flows. For example if we have OTP and WebAuthn authenticators an admin
should be able to just enabled WebAuthn, not have to create a new flow to
add it. Obviously a new custom flow would be required if the flow or custom
authenticators are added. Moving OTP policy from realm to authenticator is
already planned work, it was only added to the realm in the first place as
it was done before we had configurable authenticators.


>
>
> c) Authentication screens for the user
>
>
>
> When the user logs in, unless he has something like a cookie he will see
> by default the first configuration interface configured in the current
> Authentication factor. If there are many different factors configured, he
> can access a list of any valid authenticator to use. If the user fails with
> the selected authenticator, he may choose another configured authenticator
> to validate the step.
>

When it comes to default that is the users choice. So as a user if I have
chosen webauthn as my default that should be shown first to me, even if the
realm has the OTP as the first/default. It's also not when the user fails
with the selected authenticator, but rather allow the user to choose a
different authenticator.


>
>
> d) REST API
>
>
>
> There's no major change here, aside from updating the scheme to support
> the separation between authenticator categories and executions, and adding
> instructions to edit which authenticator categories are assigned to an
> authentication factor.
>
>
>
> e) database modifications
>
>
>
> Authenticator categories could be separated from executions either by
> having a new dedicated table, or by introducing a field in the
> authentication_execution table
>

Realm config is responsible for most of the mess in the tables today. It's
just plain daft to save this as separate tables/columns as it's always
fetched as one blog and never queried. So I wonder if we could take a first
start at this by simply storing the whole authentication flow including
authenticator config as a single JSON blob in the DB.


>
>
>
>
> 3) Design proposal for KEYCLOAK-9694
> <https://issues.jboss.org/browse/KEYCLOAK-9694>
>
>
>
> a) Changes to the users > Credential menu
>
>
>
> Instead of manage Password we have "manage credentials", with a list of
> credentials for a user. The credentials grouped by type, and should
> indicate by which authentication factor they are valid for (1st factor, 2nd
> factor, unconfigured). The administrator should be able to edit / remove a
> credential.
>
>
>
> - For editing the administrator should be able to visualise the data of
> the credential (except the secret and the salt) and edit metadata about a
> device. Data would be any data in the fields of the credential that
> describe immutable data about the credential, and metadata would be for
> example label that a user can see and edit to name his device and a label
> that only the administrator could see and edit. The administrator (and
> user) should be able to set a "preferred credential" for each
> authentication factor level, which will override the factor shown by
> default during the login.
>
>
>
> - For deleting, I think that this should be linked to the authentication
> factors and authenticator categories of the realm, for example:
>
>    + For a realm with a single factor configured of types password and
> FIDO2, the credentials can be removed until ONE remains, and that last one
> cannot be removed.
>
>    + For a realm with a two factors configured, the first with password
> and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very
> good example from a security point of view), then it must be impossible to
> remove the last credential for the first factor, and to remove the last
> credential for the second factor.
>
>
>
> A note for passwords: Unlike other credentials I don't think that there
> should be more than one password that can be configured. Also, among its
> edition option it should be possible to reset (temporarily or not) as is
> currently the case.
>
>
>
> If the administrator and user can remove credentials, I do not know if the
> possibility to disable credentials is still useful. I don't see any
> problems with the feature either though, so if it?s still deemed useful it
> would keep its current behaviour.
>

Credentials needs to have some metadata associated with them. Does it
support a user to have mutiple (passwords is a single, webauthn is
multiple). Can the admin update the value (passwords admin can update,
webauthn only users can and that's through application initiated actions
which account console will use). The thinking with regards to
adding/updating credentials is that users do it through actions (required
or application initiated), while admins do it directly in the console (in
which case we need to have a dynamic way to specify the values, something
like how component model works).


>
>
> b) Modifications to the REST API
>
>
>
> Currently there's no way to get credentials with the REST API. This should
> change with these modifications to reflect the new options for the
> administrator. The API should function in the same manner as the admin
> console: Credentials can be exposed (except for secret and hash values),
> the metadata edited and the credentials deleted with the same restrictions
> as described in section 3a
>

We just need to be very careful here that secrets are never returned on a
REST endpoint, but otherwise yes we need an endpoint that can list a users
credentials.


>
>
> c) Database modifications
>
>
>
> I do not believe that this modification entails any database
> modifications. The current system with credential and credential attributes
> should be sufficient for the handling of multiple authenticators.
>
>
>
>
> That's it. Comments, questions and criticism are all welcome.
> ------------------------------
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* 08 March 2019 13:17
> *To:* Doswald Alistair
> *Cc:* keycloak-dev
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
> No one is working on the admin part at the moment, so contributions here
> would be very welcome. It's not a straightforward task though and would
> need a fair bit of design/prototyping/discussions to get this right.
>
> On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
>> Hello,
>>
>>
>> I've been following the thread about the implementation of WebAuthn in
>> Keycloak, and saw that there are some related JIRAs in the following design
>> document
>> https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md
>> .
>>
>>
>> Is anyone  already working on JIRAs
>> https://issues.jboss.org/browse/KEYCLOAK-9693 and
>> https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd
>> factor authenticators? If not, with my colleagues we could implement them
>> relatively quickly as we have use cases for these functionalities.
>>
>>
>> Best regards,
>>
>>
>> Alistair Doswald
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From mposolda at redhat.com  Fri Mar 15 04:31:33 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 15 Mar 2019 09:31:33 +0100
Subject: [keycloak-dev] Deprecating/Removing keycloak-servlet-oauth-client
Message-ID: <ae8999d2-f225-63cb-f5d1-d62a6951d2f1@redhat.com>

We plan to deprecate and then eventually remove 
keycloak-servlet-oauth-client.? We don't officially support this client 
(it is not documented and tested) and it is additional maintenance 
overhead to have it in our codebase. Is someone around, who uses this 
client? Do you want to become a maintainer of it? If yes, let us know. 
You can fork it to your repository and we will reference it from the 
"Extensions" page [1].

Some more details about the client:

AFAIR it is one of the very early-days keycloak features and the 
use-case behind this was, that you have web frontend java application, 
which is not secured by Keycloak and doesn't use adapter. But you still 
want to have a way to invoke the REST services from this application, 
which are secured by Keycloak. So you want to trigger the OAuth flow 
manually from the Java without having the adapter to do it for you - 
that's what this client is doing.

I think that this client can be almost always replaced by adapter or by 
the servlet filter. The only case when it couldn't be replaced by 
servlet filter is, when you have non-servlet java application.

This OAuth client is unmaintained and it is missing lot of features, 
which were recently added to the adapter.

[1] https://www.keycloak.org/extensions.html

Marek


From mposolda at redhat.com  Fri Mar 15 04:32:36 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 15 Mar 2019 09:32:36 +0100
Subject: [keycloak-dev] PKCE in keycloak-servlet-oauth-client does not
 work
In-Reply-To: <CAJgngAdCAESwsMP_iZL7aU5PU1xRDn88maR+_7sdYwFkwQZPZQ@mail.gmail.com>
References: <OSBPR01MB3974AFDE6BE3D55C17985CA8CE4D0@OSBPR01MB3974.jpnprd01.prod.outlook.com>
	<CAJgngAdViNer97Yy0NXmn=vf+goSj36MZUjN9A6Ac+YPPkKbdQ@mail.gmail.com>
	<6875d5b0-784d-3e26-3b58-288b72760b1c@redhat.com>
	<CAJgngAdCAESwsMP_iZL7aU5PU1xRDn88maR+_7sdYwFkwQZPZQ@mail.gmail.com>
Message-ID: <9adb43eb-eccc-e2d0-fcfc-072293047ac6@redhat.com>

On 12/03/2019 15:02, Stian Thorgersen wrote:
>
>
> On Tue, 12 Mar 2019 at 14:38, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     It is a bit similar to recently deprecated JAXRS filter.
>
>     AFAIR it is one of the very early-days keycloak features and the
>     use-case behind this was, that you have web frontend java
>     application,
>     which is not secured by Keycloak and doesn't use adapter. But you
>     still
>     want to have a way to invoke the REST services from this application,
>     which are secured by Keycloak. So you want to trigger the OAuth flow
>     manually from the Java without having the adapter to do it for you -
>     that's what this client is doing.
>
>     I think that this client can be almost always replaced by adapter
>     or by
>     the servlet filter. The only case when it couldn't be replaced by
>     servlet filter is, when you have non-servlet java application.
>
>     This OAuth client is unmaintained and it is missing lot of features,
>     which were recently added to the adapter. I suggest to deprecate
>     it and
>     then remove in the future (or eventually move to the community
>     maintained extension if people still wants to use it?)
>
>
> +1

Created another thread on keycloak-dev and keycloak-user to ask 
community about deprecate/remove this and if someone wants to become 
maintainer.

Created JIRA https://issues.jboss.org/browse/KEYCLOAK-9836

Marek

>
>     Marek
>
>     On 08/03/2019 08:26, Stian Thorgersen wrote:
>     > I'm not sure what use-cases servlet-oauth-client aims to cover
>     and I'm not
>     > sure why we have it in the first place. It's not documented nor
>     is it well
>     > tested as far as I can tell.
>     >
>     > On Fri, 8 Mar 2019 at 03:26, ???? / NORIMATSU?TAKASHI <
>     > takashi.norimatsu.ws at hitachi.com
>     <mailto:takashi.norimatsu.ws at hitachi.com>> wrote:
>     >
>     >> Hello,
>     >>
>     >> I had contributed server side PKCE (RFC 7636 Proof Key for Code
>     Exchange)
>     >> support for keycloak and merged.
>     >> At that time, I had also implemented client side PKCE in
>     servlet oauth
>     >> client to demonstrate how PKCE works.
>     >>
>     >> However, it seemed that I had pushed servlet oauth client codes
>     that did
>     >> not work instead of ones used in my local environment.
>     >> Therefore, client side PKCE in servlet oauth client does not work.
>     >>
>     >> I've already known how to fix it, but it is difficult to write
>     Arquillian
>     >> integration tests.
>     >>
>     >> I've searched existing Arquillian integration tests for servlet
>     oauth
>     >> client but not found.
>     >>
>     >> Could anyone help me?
>     >>
>     >> Best regards,
>     >> Takashi Norimatsu
>     >> Hitachi Ltd.,
>     >>
>     >> _______________________________________________
>     >> 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
>
>


From mposolda at redhat.com  Fri Mar 15 04:45:01 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 15 Mar 2019 09:45:01 +0100
Subject: [keycloak-dev] KEYCLOAK-6795 / Silent token refresh for
 implicit flow
In-Reply-To: <A28D863D-C565-4400-8FC5-706EA639102C@n-k.de>
References: <CDE34CFD-308A-4D8D-857D-3D75D22A11F3@n-k.de>
	<031E9DD1-3421-4CEE-A927-FD8C9A26F333@n-k.de>
	<CACv4bCQXQ6H2bu-qFAz+NaFQbDLFLST5qZL_Xx3DJxagqwbB+g@mail.gmail.com>
	<284703E1-812B-4497-9F9C-84D263445D9E@n-k.de>
	<2981bb5d-6198-485a-9fc4-47053f692e0f@redhat.com>
	<A28D863D-C565-4400-8FC5-706EA639102C@n-k.de>
Message-ID: <dff08f5f-b9dc-a031-43c8-2e5c3921b31a@redhat.com>

On 12/03/2019 19:55, Niko K?bler wrote:
> Hi Marek,
>
> my point was not about the comments what the test is doing - that's something I can read from the code (and hopefully from a good test method name). However, every comment might be helpful.
> I struggled most with JavascriptAdapterTest to figure out, what resources I need else to execute/modify/improve the tests. So it took me half an hour to an hour to figure out, that the TestJavascriptResource class is also "part of" the test. It's located in a completely different subfolder from the actual test:
>
> testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/adapter/javascript/JavascriptAdapterTest.java
> vs.
> testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/rest/resource/TestJavascriptResource.java
>
> You see!? It starts to differ at the 3rd folder level - and then it gets deeper, and deeper, and... ;)
> And I didn't find a good documentation about how the testsuite is structured and organized.

Good point. There was recently added this document [1]. But maybe we 
still have some space for the improvement here... Regarding this 
particular case, we need to ensure that code inside the 
"TestJavascriptResource" is deployed as a provider to the server, so 
this code is executed on the server side - usually completely different 
JVM than the test JVM. That's why it is in separate place as the module 
is deployed as JAR to the server.

[1] 
https://github.com/keycloak/keycloak/blob/master/docs/test-development.md

Marek


>
> - Niko
>
>
>> Am 12.03.2019 um 14:08 schrieb Marek Posolda <mposolda at redhat.com>:
>>
>> Hi Niko,
>>
>> Thanks for the PR! I've added some comment in the github.
>>
>> Point taken regarding the tests. Maybe we have some space for improvement here. I personally trying to at least add some comments to the tests about what the test is doing etc. For example see OIDCScopeTest. Do you think it is sufficient for the 1st experience with the testsuite, or would you suggest to improve more?
>>
>> Marek
>>
>> On 11/03/2019 11:34, Niko K?bler wrote:
>>> Thanks Michal,
>>>
>>> thanks for the help.
>>> I struggled before with the notation from here https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-adapter-tests, as I needed to put the class name of the tests in quotes: -Dtest="org.keycloak.testsuite.adapter.**.*Test" - otherwise I got some shell errors.
>>>
>>> I just pushed the test, build is running.
>>> (It's like a nightmare to implement some tests, if you are not aware of all this stuff, as all your test classes are poorly (aka not-at-all) documented. If you want contributions from the community, you should change this!)
>>> Hope to get it merged soon. :)
>>>
>>> Regards,
>>> - Niko
>>>
>>>> Am 11.03.2019 um 09:45 schrieb Michal Hajas <mhajas at redhat.com>:
>>>>
>>>> Hello,
>>>>
>>>> thank you very much for the contribution.
>>>>
>>>> You can run JavascriptAdapterTest class using the following command executed from keycloak directory:
>>>>
>>>> mvn clean install -f testsuite/integration-arquillian/pom.xml -Dtest=JavascriptAdapterTest
>>>>
>>>> Best regards,
>>>> Michal
>>>>
>>>> On Sat, Mar 9, 2019 at 10:41 AM Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>> wrote:
>>>> I've just created a pull request for this issue, including docs, but still without tests.
>>>> https://github.com/keycloak/keycloak/pull/5932 <https://github.com/keycloak/keycloak/pull/5932>
>>>>
>>>> As the tests are quite complex to run, and I didn't find any information about how to run/execute just the JavascriptAdapterTest.java class without running the whole testsuite over and over again, I'd appreciate any help/hint, of how to run this test only.
>>>>
>>>> Thanks,
>>>> - Niko
>>>>
>>>>
>>>>
>>>>> Am 08.03.2019 um 13:19 schrieb Niko K?bler <niko at n-k.de <mailto:niko at n-k.de>>:
>>>>>
>>>>> Hi team,
>>>>>
>>>>> I'd like to volunteer for https://issues.jboss.org/browse/KEYCLOAK-6795 <https://issues.jboss.org/browse/KEYCLOAK-6795> as this is needed in one of my customers projects and it increases security in handling tokens in SPAs.
>>>>> I've already an idea of how to implement it (and a very rough working draft), but would like to discuss this first with someone of you.
>>>>> Anybody interested in discussing?
>>>>>
>>>>> - Niko
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From maurodewit at gmail.com  Fri Mar 15 05:35:34 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Fri, 15 Mar 2019 10:35:34 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
Message-ID: <CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>

I've started to create a simple proof of concept and want to check if I
have my facts straight.
As previously discussed this functionality should be provided by a custom
Authenticator that is configured in an authentication flow.

What I've done so far is:
- Created implementations for both the Authenticator and
AuthenticatorFactory interfaces.
- Added a set of ProviderConfigProperty instances that allow the desired
configuration.
- Perform the check if any session limits are exceeded inside the
authenticate() method of the Authenticator class. (Any session invalidation
will be performed here as well)

Now, in order to use session limiting for regular username/password form
logins, I have created a copy of the 'browser flow' and added this
Authenticator as a 'required' execution at the end of the flow.
In our case we allow IDP logins as well. And to use this functionality for
these logins, I've created a new authentication flow containing just this
Authenticator. Finally this flow is selected in the 'Post login flow' of
the IDP configuration.
For both scenarios the Authenticator seems to be triggered at the right
time and I should be able to apply the session limiting rules.

Any thoughts or comments so far?

On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com> wrote:

> Ok, thanks for the clarification.
>
> On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> It should be a pluggable part of the authentication flow and not a
>> hardcoded element. There is no other way to plug in to the authentication
>> flow other than creating an authenticator. An authenticator doesn't need to
>> provide a challenge though so it can be used in this instance.
>>
>> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am sending this e-mail because I have some questions regarding the
>>> enhancement request that enables configurable session limiting in
>>> Keycloak
>>> as discussed here:
>>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc
>>> Wijma
>>> referred to in his comment as being available for this task is me btw :))
>>>
>>> In the comments a solution is proposed that makes use of a custom
>>> Authenticator that is dropped into the authentication flow where it can
>>> be
>>> configured. While I can see the benefit of leveraging the existing
>>> components as much as possible (including the configuration options in
>>> that
>>> flow), I am wondering if this is the best solution. As far as I can tell,
>>> this component is not performing any authentication at all. Moreover this
>>> functionality operates 'above' the authentication mechanisms and should
>>> apply to all of them.
>>> So is an Authenticator really the desired place to implement this? Or is
>>> this just the quickest route, while not being the most desirable option
>>> for
>>> the long term? What would be an alternative approach be? That would place
>>> this implementation and configuration in the existing Session
>>> configuration
>>> code for instance.
>>>
>>> I just now started investigating this task and looking into the options
>>> that would meet our requirements. Hope to hear from you.
>>>
>>> Regards
>>>
>>> Mauro
>>>
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From jblashka at redhat.com  Fri Mar 15 10:23:18 2019
From: jblashka at redhat.com (Jared Blashka)
Date: Fri, 15 Mar 2019 10:23:18 -0400
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
Message-ID: <CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>

If this is done via an authenticator wouldn't you have to make sure that
this authenticator is present (and all the same settings are maintained) in
the browser flow as well as the direct access flow as well as the login
flows for all configured identity providers? It seems like it would be
quite easy to make a mistake in that process and misconfigure something
somewhere.

On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com> wrote:

> I've started to create a simple proof of concept and want to check if I
> have my facts straight.
> As previously discussed this functionality should be provided by a custom
> Authenticator that is configured in an authentication flow.
>
> What I've done so far is:
> - Created implementations for both the Authenticator and
> AuthenticatorFactory interfaces.
> - Added a set of ProviderConfigProperty instances that allow the desired
> configuration.
> - Perform the check if any session limits are exceeded inside the
> authenticate() method of the Authenticator class. (Any session invalidation
> will be performed here as well)
>
> Now, in order to use session limiting for regular username/password form
> logins, I have created a copy of the 'browser flow' and added this
> Authenticator as a 'required' execution at the end of the flow.
> In our case we allow IDP logins as well. And to use this functionality for
> these logins, I've created a new authentication flow containing just this
> Authenticator. Finally this flow is selected in the 'Post login flow' of
> the IDP configuration.
> For both scenarios the Authenticator seems to be triggered at the right
> time and I should be able to apply the session limiting rules.
>
> Any thoughts or comments so far?
>
> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com> wrote:
>
> > Ok, thanks for the clarification.
> >
> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> It should be a pluggable part of the authentication flow and not a
> >> hardcoded element. There is no other way to plug in to the
> authentication
> >> flow other than creating an authenticator. An authenticator doesn't
> need to
> >> provide a challenge though so it can be used in this instance.
> >>
> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
> wrote:
> >>
> >>> Hello,
> >>>
> >>> I am sending this e-mail because I have some questions regarding the
> >>> enhancement request that enables configurable session limiting in
> >>> Keycloak
> >>> as discussed here:
> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc
> >>> Wijma
> >>> referred to in his comment as being available for this task is me btw
> :))
> >>>
> >>> In the comments a solution is proposed that makes use of a custom
> >>> Authenticator that is dropped into the authentication flow where it can
> >>> be
> >>> configured. While I can see the benefit of leveraging the existing
> >>> components as much as possible (including the configuration options in
> >>> that
> >>> flow), I am wondering if this is the best solution. As far as I can
> tell,
> >>> this component is not performing any authentication at all. Moreover
> this
> >>> functionality operates 'above' the authentication mechanisms and should
> >>> apply to all of them.
> >>> So is an Authenticator really the desired place to implement this? Or
> is
> >>> this just the quickest route, while not being the most desirable option
> >>> for
> >>> the long term? What would be an alternative approach be? That would
> place
> >>> this implementation and configuration in the existing Session
> >>> configuration
> >>> code for instance.
> >>>
> >>> I just now started investigating this task and looking into the options
> >>> that would meet our requirements. Hope to hear from you.
> >>>
> >>> Regards
> >>>
> >>> Mauro
> >>>
> >>> >
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Fri Mar 15 19:13:37 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Mar 2019 20:13:37 -0300
Subject: [keycloak-dev] Changes for Quarkus Extension
Message-ID: <CAJrcDBd8nd5E+2dnh7TpA1HqC7LMLK9MfboEdQFFv6W0smvi9A@mail.gmail.com>

Hello All,

We are finally close to finishing the Keycloak Quarkus Extension. An
extension that will help developers to protect their services using both
JVM and Native mode based on the existing functionality provided by our
adapters. In this case, by the Undertow Adapter.

After discussing with Scott Stark different approaches to this extension,
we finally have an agreement that will require two changes in the adapter
code.

The first one is quite simple as it is basically defining a constructor to
the KeycloakServletExtension in order to allow passing a pre-built
AdapterDeploymentContext instance [1]. This change will give more
flexibility to the extension to build the deployment context and use it to
configure the deployment. For instance, we could read keycloak related
settings from the Quarkus configuration instead of keycloak.json.

The second one is about lazy loading the HttpClient and to avoid creating a
new instance during the deployment configuration. But produce a new
instance only when a new instance is required. The main reason for this
change is to overcome some issues in Quarkus when generating native images
using the extension. Scott Stark started a thread [2] about this issue in
particular. In a nutshell, we are basically delaying the initialization of
HttpClient (and mainly its dependencies to some security related classes in
the JDK) to runtime.

Please, let me know what you think about these two changes, specially the
second one. I can not think about any issue that the lazy initialization of
the HttpClient can cause (considering concurrency issues), but maybe I'm
missing something.

[1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
[2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY

Regards,
Pedro Igor

From psilva at redhat.com  Fri Mar 15 19:19:19 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Mar 2019 20:19:19 -0300
Subject: [keycloak-dev] Changes for Quarkus Extension
In-Reply-To: <CAJrcDBd8nd5E+2dnh7TpA1HqC7LMLK9MfboEdQFFv6W0smvi9A@mail.gmail.com>
References: <CAJrcDBd8nd5E+2dnh7TpA1HqC7LMLK9MfboEdQFFv6W0smvi9A@mail.gmail.com>
Message-ID: <CAJrcDBdoD3aroE4mv4xXyadf__--fRJMmUHTRLNe2EWiOgDMSg@mail.gmail.com>

Btw, we are also depending on the following issue in Quarkus [3].

[3] https://github.com/quarkusio/quarkus/pull/1530

On Fri, Mar 15, 2019 at 8:13 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Hello All,
>
> We are finally close to finishing the Keycloak Quarkus Extension. An
> extension that will help developers to protect their services using both
> JVM and Native mode based on the existing functionality provided by our
> adapters. In this case, by the Undertow Adapter.
>
> After discussing with Scott Stark different approaches to this extension,
> we finally have an agreement that will require two changes in the adapter
> code.
>
> The first one is quite simple as it is basically defining a constructor to
> the KeycloakServletExtension in order to allow passing a pre-built
> AdapterDeploymentContext instance [1]. This change will give more
> flexibility to the extension to build the deployment context and use it to
> configure the deployment. For instance, we could read keycloak related
> settings from the Quarkus configuration instead of keycloak.json.
>
> The second one is about lazy loading the HttpClient and to avoid creating
> a new instance during the deployment configuration. But produce a new
> instance only when a new instance is required. The main reason for this
> change is to overcome some issues in Quarkus when generating native images
> using the extension. Scott Stark started a thread [2] about this issue in
> particular. In a nutshell, we are basically delaying the initialization of
> HttpClient (and mainly its dependencies to some security related classes in
> the JDK) to runtime.
>
> Please, let me know what you think about these two changes, specially the
> second one. I can not think about any issue that the lazy initialization of
> the HttpClient can cause (considering concurrency issues), but maybe I'm
> missing something.
>
> [1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
> [2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY
>
> Regards,
> Pedro Igor
>

From sguilhen at redhat.com  Fri Mar 15 20:43:45 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Fri, 15 Mar 2019 21:43:45 -0300
Subject: [keycloak-dev] Changes for Quarkus Extension
In-Reply-To: <CAJrcDBdoD3aroE4mv4xXyadf__--fRJMmUHTRLNe2EWiOgDMSg@mail.gmail.com>
References: <CAJrcDBd8nd5E+2dnh7TpA1HqC7LMLK9MfboEdQFFv6W0smvi9A@mail.gmail.com>
	<CAJrcDBdoD3aroE4mv4xXyadf__--fRJMmUHTRLNe2EWiOgDMSg@mail.gmail.com>
Message-ID: <CA+7ohfkb5HoeziUuVtaHiSVn8Rsdp7zMAdMP6JqO3W4QaZ156w@mail.gmail.com>

I think both changes are very reasonable, including the workaround for #2.

On Fri, Mar 15, 2019, 20:25 Pedro Igor Silva <psilva at redhat.com> wrote:

> Btw, we are also depending on the following issue in Quarkus [3].
>
> [3] https://github.com/quarkusio/quarkus/pull/1530
>
> On Fri, Mar 15, 2019 at 8:13 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
> > Hello All,
> >
> > We are finally close to finishing the Keycloak Quarkus Extension. An
> > extension that will help developers to protect their services using both
> > JVM and Native mode based on the existing functionality provided by our
> > adapters. In this case, by the Undertow Adapter.
> >
> > After discussing with Scott Stark different approaches to this extension,
> > we finally have an agreement that will require two changes in the adapter
> > code.
> >
> > The first one is quite simple as it is basically defining a constructor
> to
> > the KeycloakServletExtension in order to allow passing a pre-built
> > AdapterDeploymentContext instance [1]. This change will give more
> > flexibility to the extension to build the deployment context and use it
> to
> > configure the deployment. For instance, we could read keycloak related
> > settings from the Quarkus configuration instead of keycloak.json.
> >
> > The second one is about lazy loading the HttpClient and to avoid creating
> > a new instance during the deployment configuration. But produce a new
> > instance only when a new instance is required. The main reason for this
> > change is to overcome some issues in Quarkus when generating native
> images
> > using the extension. Scott Stark started a thread [2] about this issue in
> > particular. In a nutshell, we are basically delaying the initialization
> of
> > HttpClient (and mainly its dependencies to some security related classes
> in
> > the JDK) to runtime.
> >
> > Please, let me know what you think about these two changes, specially the
> > second one. I can not think about any issue that the lazy initialization
> of
> > the HttpClient can cause (considering concurrency issues), but maybe I'm
> > missing something.
> >
> > [1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
> > [2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY
> >
> > Regards,
> > Pedro Igor
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From maurodewit at gmail.com  Mon Mar 18 04:00:39 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Mon, 18 Mar 2019 09:00:39 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
Message-ID: <CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>

That is indeed one of the downsides of this approach.
But can a misconfiguration of this functionality do any harm, besides some
inconsistent behavior between authentication methods?

@stian at redhat.com <stian at redhat.com> any thoughts?

On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com> wrote:

> If this is done via an authenticator wouldn't you have to make sure that
> this authenticator is present (and all the same settings are maintained) in
> the browser flow as well as the direct access flow as well as the login
> flows for all configured identity providers? It seems like it would be
> quite easy to make a mistake in that process and misconfigure something
> somewhere.
>
> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> I've started to create a simple proof of concept and want to check if I
>> have my facts straight.
>> As previously discussed this functionality should be provided by a custom
>> Authenticator that is configured in an authentication flow.
>>
>> What I've done so far is:
>> - Created implementations for both the Authenticator and
>> AuthenticatorFactory interfaces.
>> - Added a set of ProviderConfigProperty instances that allow the desired
>> configuration.
>> - Perform the check if any session limits are exceeded inside the
>> authenticate() method of the Authenticator class. (Any session
>> invalidation
>> will be performed here as well)
>>
>> Now, in order to use session limiting for regular username/password form
>> logins, I have created a copy of the 'browser flow' and added this
>> Authenticator as a 'required' execution at the end of the flow.
>> In our case we allow IDP logins as well. And to use this functionality for
>> these logins, I've created a new authentication flow containing just this
>> Authenticator. Finally this flow is selected in the 'Post login flow' of
>> the IDP configuration.
>> For both scenarios the Authenticator seems to be triggered at the right
>> time and I should be able to apply the session limiting rules.
>>
>> Any thoughts or comments so far?
>>
>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>> > Ok, thanks for the clarification.
>> >
>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
>> > wrote:
>> >
>> >> It should be a pluggable part of the authentication flow and not a
>> >> hardcoded element. There is no other way to plug in to the
>> authentication
>> >> flow other than creating an authenticator. An authenticator doesn't
>> need to
>> >> provide a challenge though so it can be used in this instance.
>> >>
>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I am sending this e-mail because I have some questions regarding the
>> >>> enhancement request that enables configurable session limiting in
>> >>> Keycloak
>> >>> as discussed here:
>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc
>> >>> Wijma
>> >>> referred to in his comment as being available for this task is me btw
>> :))
>> >>>
>> >>> In the comments a solution is proposed that makes use of a custom
>> >>> Authenticator that is dropped into the authentication flow where it
>> can
>> >>> be
>> >>> configured. While I can see the benefit of leveraging the existing
>> >>> components as much as possible (including the configuration options in
>> >>> that
>> >>> flow), I am wondering if this is the best solution. As far as I can
>> tell,
>> >>> this component is not performing any authentication at all. Moreover
>> this
>> >>> functionality operates 'above' the authentication mechanisms and
>> should
>> >>> apply to all of them.
>> >>> So is an Authenticator really the desired place to implement this? Or
>> is
>> >>> this just the quickest route, while not being the most desirable
>> option
>> >>> for
>> >>> the long term? What would be an alternative approach be? That would
>> place
>> >>> this implementation and configuration in the existing Session
>> >>> configuration
>> >>> code for instance.
>> >>>
>> >>> I just now started investigating this task and looking into the
>> options
>> >>> that would meet our requirements. Hope to hear from you.
>> >>>
>> >>> Regards
>> >>>
>> >>> Mauro
>> >>>
>> >>> >
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>
>> >>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Mon Mar 18 04:19:48 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Mar 2019 09:19:48 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
Message-ID: <CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>

The authenticator should be added after the cookie authenticator, not at
the end. That will make it take affect for IdP logins as well. So it's a
matter of configuring it in two flows browser and direct grant.

I appreciate it may not be the best usability, but I don't want to
introduce something special/hard-coded for this feature. A later
improvement could be to improve on the authentication flows. To have
different elements in a flow and not just executions as well as potentially
having some pre-flow checks that are done in all flows. I'd say this
approach is good enough though at least for now.

On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com> wrote:

> That is indeed one of the downsides of this approach.
> But can a misconfiguration of this functionality do any harm, besides some
> inconsistent behavior between authentication methods?
>
> @stian at redhat.com <stian at redhat.com> any thoughts?
>
> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com> wrote:
>
>> If this is done via an authenticator wouldn't you have to make sure that
>> this authenticator is present (and all the same settings are maintained) in
>> the browser flow as well as the direct access flow as well as the login
>> flows for all configured identity providers? It seems like it would be
>> quite easy to make a mistake in that process and misconfigure something
>> somewhere.
>>
>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>> wrote:
>>
>>> I've started to create a simple proof of concept and want to check if I
>>> have my facts straight.
>>> As previously discussed this functionality should be provided by a custom
>>> Authenticator that is configured in an authentication flow.
>>>
>>> What I've done so far is:
>>> - Created implementations for both the Authenticator and
>>> AuthenticatorFactory interfaces.
>>> - Added a set of ProviderConfigProperty instances that allow the desired
>>> configuration.
>>> - Perform the check if any session limits are exceeded inside the
>>> authenticate() method of the Authenticator class. (Any session
>>> invalidation
>>> will be performed here as well)
>>>
>>> Now, in order to use session limiting for regular username/password form
>>> logins, I have created a copy of the 'browser flow' and added this
>>> Authenticator as a 'required' execution at the end of the flow.
>>> In our case we allow IDP logins as well. And to use this functionality
>>> for
>>> these logins, I've created a new authentication flow containing just this
>>> Authenticator. Finally this flow is selected in the 'Post login flow' of
>>> the IDP configuration.
>>> For both scenarios the Authenticator seems to be triggered at the right
>>> time and I should be able to apply the session limiting rules.
>>>
>>> Any thoughts or comments so far?
>>>
>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com> wrote:
>>>
>>> > Ok, thanks for the clarification.
>>> >
>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
>>> > wrote:
>>> >
>>> >> It should be a pluggable part of the authentication flow and not a
>>> >> hardcoded element. There is no other way to plug in to the
>>> authentication
>>> >> flow other than creating an authenticator. An authenticator doesn't
>>> need to
>>> >> provide a challenge though so it can be used in this instance.
>>> >>
>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>> wrote:
>>> >>
>>> >>> Hello,
>>> >>>
>>> >>> I am sending this e-mail because I have some questions regarding the
>>> >>> enhancement request that enables configurable session limiting in
>>> >>> Keycloak
>>> >>> as discussed here:
>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that
>>> Marc
>>> >>> Wijma
>>> >>> referred to in his comment as being available for this task is me
>>> btw :))
>>> >>>
>>> >>> In the comments a solution is proposed that makes use of a custom
>>> >>> Authenticator that is dropped into the authentication flow where it
>>> can
>>> >>> be
>>> >>> configured. While I can see the benefit of leveraging the existing
>>> >>> components as much as possible (including the configuration options
>>> in
>>> >>> that
>>> >>> flow), I am wondering if this is the best solution. As far as I can
>>> tell,
>>> >>> this component is not performing any authentication at all. Moreover
>>> this
>>> >>> functionality operates 'above' the authentication mechanisms and
>>> should
>>> >>> apply to all of them.
>>> >>> So is an Authenticator really the desired place to implement this?
>>> Or is
>>> >>> this just the quickest route, while not being the most desirable
>>> option
>>> >>> for
>>> >>> the long term? What would be an alternative approach be? That would
>>> place
>>> >>> this implementation and configuration in the existing Session
>>> >>> configuration
>>> >>> code for instance.
>>> >>>
>>> >>> I just now started investigating this task and looking into the
>>> options
>>> >>> that would meet our requirements. Hope to hear from you.
>>> >>>
>>> >>> Regards
>>> >>>
>>> >>> Mauro
>>> >>>
>>> >>> >
>>> >>> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>
>>> >>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Mon Mar 18 04:49:24 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Mar 2019 09:49:24 +0100
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
	extension
In-Reply-To: <TY2PR01MB4540B5A73CE0F24E85DD3FABC9440@TY2PR01MB4540.jpnprd01.prod.outlook.com>
References: <TY2PR01MB4540B5A73CE0F24E85DD3FABC9440@TY2PR01MB4540.jpnprd01.prod.outlook.com>
Message-ID: <CAJgngAeDQ6EooN-bV5KSMWEa4ncFNDEk0FnOWZyLHND7SQW-6A@mail.gmail.com>

Tried this out today and it didn't work for me. I was getting some JS error
both on Chrome and Firefox when trying to register authenticator.

One comment is that it shouldn't create a new table, but rather just
serialize the value to the existing credential table in the same way as the
FIDO U2F example does [1].

[1] https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f

On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI <
yuichi.nakamura.fe at hitachi.com> wrote:

> Hi,
>
> We?ve uploaded the initial prototype of webauthn authenticator below:
> https://github.com/webauthn4j/keycloak-webauthn-authenticator
>
> Feedback is welcomed.
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Thursday, February 28, 2019 6:53 PM
> To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an
> WebAuthn4j extension
>
> That's great, thanks.
>
> Do you have an idea on roughly when you can have a prototype ready?
>
> On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> My team has begun to help webauthn4j project,
> and is going to develop prototype of authenticator for keycloak.
> We'd like to take this.
>
> Regards,
> Yuichi Nakamura
> Hitachi, Ltd.
>
> -----Original Message-----
> From: mailto:keycloak-dev-bounces at lists.jboss.org <mailto:
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Thursday, February 28, 2019 12:26 AM
> To: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
> Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j
> extension
>
> A while back I created an experimental extension to Keycloak for FIDO U2F.
> It would be great if someone could adapt this to WebAuthn by leveraging
> webauthn4j library [1].
>
> Any takers? It shouldn't be hard ;)
>
> [1]
> https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
> _______________________________________________
> keycloak-dev mailing list
> mailto:keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>

From alistair.doswald at elca.ch  Mon Mar 18 05:51:14 2019
From: alistair.doswald at elca.ch (Doswald Alistair)
Date: Mon, 18 Mar 2019 09:51:14 +0000
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
 implementing JIRAs
In-Reply-To: <CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
	<111481de90e245cabb85e75fa4f72c70@elca.ch>
	<CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>
Message-ID: <685b12117e024c449ae6e1a4e221cac8@elca.ch>

* I can move the design proposal to https://github.com/keycloak/keycloak-community/tree/master/design. For this I simply format in Markdown and do a pull request?

* I?d also be in favour of a face to face meeting. I?m in the CET timezone (currently GMT+1 and GMT+2 from the 31st of march). This week I?d be available Tuesday, Thursday and Friday, and I also have availabilities next week (except Monday). I?m not sure of the logistics however? We use skype for business internally, but maybe you have a preferred platform? Also, would you mind if one of my colleagues who could work on the JIRAs joins the meeting call?
* Since I?m answering anyway, I?ll answer a few of your comments (the rest can be discussed later as I think that they are more technical):

- I believe that you?re correct to say that we should consider the step-up (and one of my colleagues actually had the same comment upon reading my proposal). I may have some ideas on how this would work with the proposed 2 factor, but I?d like to read up on what was already discussed/proposed first. Has there been more discussed than what?s at https://issues.jboss.org/browse/KEYCLOAK-847, http://lists.jboss.org/pipermail/keycloak-user/2016-November/008311.html, http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007150.html and http://lists.jboss.org/pipermail/keycloak-dev/2017-April/009245.html?

- For the users setting their own default authenticator I agree (and intended to describe that in the text, though upon re-reading that part of the description is fragmented), as long as the admin has enabled the authentication category in a flow. However, it is true that between the default flow and custom/per-client flows it may be difficult to determine how the user sees/selects his preferred authenticator for an authentication step (not to mention what would happen when an admin changes the configuration). This should definitely be further detailed. I?m not sure yet if some extra data structures are necessary though, maybe some custom functions to get the required information is sufficient.


- I think that having a built in flow that follows the proposed logic isn?t too difficult. There?d be the ?Authenticated on?,
?Authentication factor 1? and ?Authentication factor 2? executions with some default authenticator categories. The admin would be able to set enabled and disabled for the built-in authenticator categories, but be able to add and remove in custom flows. That way a newbie admin wouldn?t be able to do too much damage, while a more experienced one would be able to customize as he wants. Some extra documentation within the admin console may help with this.


From: Stian Thorgersen <sthorger at redhat.com>
Sent: vendredi 15 mars 2019 09:25
To: Doswald Alistair <alistair.doswald at elca.ch>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs

* Would be worth moving this to a design proposal on https://github.com/keycloak/keycloak-community/tree/master/design. Would be easier to work collectively on a design proposal there than to have an endless thread on a ML ;). I'd also be open to join you on a call to have a discussion "face to face"

* I was thinking to limit to two factor for now, but you're probably right here with regards to consider the bigger picture now as it may be difficult to get it right otherwise

* Need to consider how this fits into step-up authentication

* Admins should be able to select level of authentication required, but users should be able to choose from available options

* Users should be able to select from available mechanisms when configuring. Users should be able to set their own default. This means the account console/rest needs metadata to discover available mechanisms. I wonder if there's a need for something outside of flows and authenticators to capture metadata about supported credential types which is used by account and admin consoles to manage credentials.

* I was aiming a simpler setup where admin doesn't need to create custom flow unless they want to add custom authenticators. That means authenticators should be enabled/disabled in the flow rather than added/removed

Some more comments inline below

On Thu, 14 Mar 2019 at 14:02, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:

This is OK for me. I propose starting with initial proposals for the fundamentals in this email, and once there's an agreement on those, separating the discussion between the two JIRAs to refine the concepts for each one. Once the work to be done is clearer, it can be supplemented with screen mockups and/or prototypes.





1) Scope of the modifications



- For JIRA KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>, I believe that the description in the JIRA is not general enough to cover the description in web-authn-two-factor.md<https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>. Modifications to the authentication flows should support single factor, as well as 2nd factor and allow both authentication factor levels to select the alternative types of authenticator to be used. This allows a single factor authentication to use for example a FIDO2 dongle for passwordless authentication, or even let the user choose between the dongle and a password during the login.  Modifications for this JIRA include: changes to the authentication logic, changes to the authentication part of the admin console, changes to the authentication screens that the user sees during login, changes to the REST API, and possibly some changes to the database.

In the first round we are focusing on two factor. Follow-up later is passwordless flows for web-authn. Passwordless is more tricky as it requires identity first login flow, ability for users to somehow define how they authenticate, rather than just what the second factor is, ability for admins to define authentication optoins rather than just two factor options.

As I mentioned above though it is probably all to linked to consider only one at the design phase. So perhaps we need to work together on a design proposal that will include everything including step-up authentication.




- For JIRA KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>, changes are to the "users > credentials" part of the administration console and to the REST API.





2) Design proposal for KEYCLOAK-9693<https://issues.jboss.org/browse/KEYCLOAK-9693>



a) Authentication logic



The current authentication flow system should be kept, but perhaps simplified. For a start I think that actual authenticators categories - that is elements that provide identity (e.g. password, cookie, kerberos, otp, fido, ...) - should be separate from other executions like "reset password".



Thus, instead of directly adding "cookie" or "password" as alternatives in the authentication flow, the user can add the execution "authentication factor", and under authentication factor he can add only the valid authenticator categories. Each of the authenticator categories under the authentication factor are considered valid alternatives, and are evaluated in order. The authentication stops being automatically evaluated at the first authenticator that requires user input (alternative: all non-user input authenticators are evaluated before the first user-input authenticator).



Adding a 2nd "authentication factor" execution sets the 2nd factor, and it must then have authenticators assigned. To have an authenticator category be valid for both authentication factors it must be set under both 1st and 2nd authentication factor. For example, kerberos could be set for both 1st and 2nd factor, which would mean that the user skips both factors if he's registered with kerberos, but it could also be just set for the first factor, in which case he'd still have to input the 2nd factor. To handle optional 2nd factors there could either be a "optional authentication factor type" or have an "optional" flag in the options of the "authentication factor".



Potentially, this system could also allow a company that's really security conscientious/paranoiac to set N factors.



Authentication factors are treated as a bloc in the evaluation of alternatives. That is, if in a flow there's "Identity provider redirector", "authentication factor 1", "authentication factor 2", entering the authentication factor 1 flow will automatically cause "authentication factor 2" to be executed after.



To make things perhaps a little more clear, the current default "Browser" authentication would become for example:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2) [OPTIONAL]

  |- Cookie

  |- Kerberos

  |- OTP Form



And if we wanted to have an mandatory 2nd factor, with either OTP or a FIDO2 configured:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authentication factor (1)

  |- Cookie

  |- Kerberos

  |- Username Password Form

Authentication factor (2)

  |- Cookie

  |- Kerberos

  |- OTP Form

  |- FIDO-2



Potentially we could also introduce another type of authentication execution, we could call it "Authenticated on", to simplify the authenticators that bypass the authentication factors. We could then have:



Auth type

------------------------------------------------------------

Identity Provider Redirector

Authenticated on

  |- Cookie

  |- Kerberos

Authentication factor (1)

  |- Username Password Form

Authentication factor (2)

  |- OTP Form

  |- FIDO-2

I like this in general. Devil is in the detail here though and need to think about this some more, especially how it fits into step-up-authentication.




b) Authentication section in the admin console



The schema described in a) would be implemented in the Authentication > flows. Bindings and Required Actions don't need any change I think. For policies I believe the password policy for the realm should remain, but the OTP policy should disappear, as a user could have several alternative OTP devices with different settings. As such, the information about the OTP settings should probably move to information associated with the credential.

+1 I also think this is limited to the flow itself. Bear in mind I want to have a built-in flow that can be configured rather than requiring creating new flows. For example if we have OTP and WebAuthn authenticators an admin should be able to just enabled WebAuthn, not have to create a new flow to add it. Obviously a new custom flow would be required if the flow or custom authenticators are added. Moving OTP policy from realm to authenticator is already planned work, it was only added to the realm in the first place as it was done before we had configurable authenticators.




c) Authentication screens for the user



When the user logs in, unless he has something like a cookie he will see by default the first configuration interface configured in the current Authentication factor. If there are many different factors configured, he can access a list of any valid authenticator to use. If the user fails with the selected authenticator, he may choose another configured authenticator to validate the step.

When it comes to default that is the users choice. So as a user if I have chosen webauthn as my default that should be shown first to me, even if the realm has the OTP as the first/default. It's also not when the user fails with the selected authenticator, but rather allow the user to choose a different authenticator.




d) REST API



There's no major change here, aside from updating the scheme to support the separation between authenticator categories and executions, and adding instructions to edit which authenticator categories are assigned to an authentication factor.



e) database modifications



Authenticator categories could be separated from executions either by having a new dedicated table, or by introducing a field in the authentication_execution table

Realm config is responsible for most of the mess in the tables today. It's just plain daft to save this as separate tables/columns as it's always fetched as one blog and never queried. So I wonder if we could take a first start at this by simply storing the whole authentication flow including authenticator config as a single JSON blob in the DB.






3) Design proposal for KEYCLOAK-9694<https://issues.jboss.org/browse/KEYCLOAK-9694>



a) Changes to the users > Credential menu



Instead of manage Password we have "manage credentials", with a list of credentials for a user. The credentials grouped by type, and should indicate by which authentication factor they are valid for (1st factor, 2nd factor, unconfigured). The administrator should be able to edit / remove a credential.



- For editing the administrator should be able to visualise the data of the credential (except the secret and the salt) and edit metadata about a device. Data would be any data in the fields of the credential that describe immutable data about the credential, and metadata would be for example label that a user can see and edit to name his device and a label that only the administrator could see and edit. The administrator (and user) should be able to set a "preferred credential" for each authentication factor level, which will override the factor shown by default during the login.



- For deleting, I think that this should be linked to the authentication factors and authenticator categories of the realm, for example:

   + For a realm with a single factor configured of types password and FIDO2, the credentials can be removed until ONE remains, and that last one cannot be removed.

   + For a realm with a two factors configured, the first with password and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very good example from a security point of view), then it must be impossible to remove the last credential for the first factor, and to remove the last credential for the second factor.



A note for passwords: Unlike other credentials I don't think that there should be more than one password that can be configured. Also, among its edition option it should be possible to reset (temporarily or not) as is currently the case.



If the administrator and user can remove credentials, I do not know if the possibility to disable credentials is still useful. I don't see any problems with the feature either though, so if it?s still deemed useful it would keep its current behaviour.

Credentials needs to have some metadata associated with them. Does it support a user to have mutiple (passwords is a single, webauthn is multiple). Can the admin update the value (passwords admin can update, webauthn only users can and that's through application initiated actions which account console will use). The thinking with regards to adding/updating credentials is that users do it through actions (required or application initiated), while admins do it directly in the console (in which case we need to have a dynamic way to specify the values, something like how component model works).




b) Modifications to the REST API



Currently there's no way to get credentials with the REST API. This should change with these modifications to reflect the new options for the administrator. The API should function in the same manner as the admin console: Credentials can be exposed (except for secret and hash values), the metadata edited and the credentials deleted with the same restrictions as described in section 3a

We just need to be very careful here that secrets are never returned on a REST endpoint, but otherwise yes we need an endpoint that can list a users credentials.




c) Database modifications



I do not believe that this modification entails any database modifications. The current system with credential and credential attributes should be sufficient for the handling of multiple authenticators.







That's it. Comments, questions and criticism are all welcome.

________________________________
From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Sent: 08 March 2019 13:17
To: Doswald Alistair
Cc: keycloak-dev
Subject: Re: [keycloak-dev] W3C Web Authentication - Two-Factor, implementing JIRAs

No one is working on the admin part at the moment, so contributions here would be very welcome. It's not a straightforward task though and would need a fair bit of design/prototyping/discussions to get this right.

On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch<mailto:alistair.doswald at elca.ch>> wrote:
Hello,


I've been following the thread about the implementation of WebAuthn in Keycloak, and saw that there are some related JIRAs in the following design document https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md.


Is anyone  already working on JIRAs https://issues.jboss.org/browse/KEYCLOAK-9693 and https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd factor authenticators? If not, with my colleagues we could implement them relatively quickly as we have use cases for these functionalities.


Best regards,


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

From maurodewit at gmail.com  Mon Mar 18 05:58:49 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Mon, 18 Mar 2019 10:58:49 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
Message-ID: <CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>

Ok, I'm missing some fundamental understanding here. Please help :)

In case of the browser flow, the authentication flow is executed upon
loading a page using the browser. At this time checks are being performed
to see if the user is already logged on. If this is the case, no
authentication has to be performed and the user is presented the requested
page.
But if the user is not yet logged on, the cookie authenticator can't do
anything usefull resulting in the next authenticator to trigger. Eventually
the 'browser forms' authenticator presents a login screen.

Given the fact that we need to deny the user access in case a session
already exists for his/her account on another machine, we need to know who
this user is. How can we know which user we are dealing with at the start
of the flow?
I can see this working for limiting the number of sessions for each realm,
but not for limiting sessions bound to individual user accounts.



On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com> wrote:

> The authenticator should be added after the cookie authenticator, not at
> the end. That will make it take affect for IdP logins as well. So it's a
> matter of configuring it in two flows browser and direct grant.
>
> I appreciate it may not be the best usability, but I don't want to
> introduce something special/hard-coded for this feature. A later
> improvement could be to improve on the authentication flows. To have
> different elements in a flow and not just executions as well as potentially
> having some pre-flow checks that are done in all flows. I'd say this
> approach is good enough though at least for now.
>
> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> That is indeed one of the downsides of this approach.
>> But can a misconfiguration of this functionality do any harm, besides
>> some inconsistent behavior between authentication methods?
>>
>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>
>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com> wrote:
>>
>>> If this is done via an authenticator wouldn't you have to make sure that
>>> this authenticator is present (and all the same settings are maintained) in
>>> the browser flow as well as the direct access flow as well as the login
>>> flows for all configured identity providers? It seems like it would be
>>> quite easy to make a mistake in that process and misconfigure something
>>> somewhere.
>>>
>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>> wrote:
>>>
>>>> I've started to create a simple proof of concept and want to check if I
>>>> have my facts straight.
>>>> As previously discussed this functionality should be provided by a
>>>> custom
>>>> Authenticator that is configured in an authentication flow.
>>>>
>>>> What I've done so far is:
>>>> - Created implementations for both the Authenticator and
>>>> AuthenticatorFactory interfaces.
>>>> - Added a set of ProviderConfigProperty instances that allow the desired
>>>> configuration.
>>>> - Perform the check if any session limits are exceeded inside the
>>>> authenticate() method of the Authenticator class. (Any session
>>>> invalidation
>>>> will be performed here as well)
>>>>
>>>> Now, in order to use session limiting for regular username/password form
>>>> logins, I have created a copy of the 'browser flow' and added this
>>>> Authenticator as a 'required' execution at the end of the flow.
>>>> In our case we allow IDP logins as well. And to use this functionality
>>>> for
>>>> these logins, I've created a new authentication flow containing just
>>>> this
>>>> Authenticator. Finally this flow is selected in the 'Post login flow' of
>>>> the IDP configuration.
>>>> For both scenarios the Authenticator seems to be triggered at the right
>>>> time and I should be able to apply the session limiting rules.
>>>>
>>>> Any thoughts or comments so far?
>>>>
>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>> > Ok, thanks for the clarification.
>>>> >
>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
>>>> > wrote:
>>>> >
>>>> >> It should be a pluggable part of the authentication flow and not a
>>>> >> hardcoded element. There is no other way to plug in to the
>>>> authentication
>>>> >> flow other than creating an authenticator. An authenticator doesn't
>>>> need to
>>>> >> provide a challenge though so it can be used in this instance.
>>>> >>
>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>> >>
>>>> >>> Hello,
>>>> >>>
>>>> >>> I am sending this e-mail because I have some questions regarding the
>>>> >>> enhancement request that enables configurable session limiting in
>>>> >>> Keycloak
>>>> >>> as discussed here:
>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that
>>>> Marc
>>>> >>> Wijma
>>>> >>> referred to in his comment as being available for this task is me
>>>> btw :))
>>>> >>>
>>>> >>> In the comments a solution is proposed that makes use of a custom
>>>> >>> Authenticator that is dropped into the authentication flow where it
>>>> can
>>>> >>> be
>>>> >>> configured. While I can see the benefit of leveraging the existing
>>>> >>> components as much as possible (including the configuration options
>>>> in
>>>> >>> that
>>>> >>> flow), I am wondering if this is the best solution. As far as I can
>>>> tell,
>>>> >>> this component is not performing any authentication at all.
>>>> Moreover this
>>>> >>> functionality operates 'above' the authentication mechanisms and
>>>> should
>>>> >>> apply to all of them.
>>>> >>> So is an Authenticator really the desired place to implement this?
>>>> Or is
>>>> >>> this just the quickest route, while not being the most desirable
>>>> option
>>>> >>> for
>>>> >>> the long term? What would be an alternative approach be? That would
>>>> place
>>>> >>> this implementation and configuration in the existing Session
>>>> >>> configuration
>>>> >>> code for instance.
>>>> >>>
>>>> >>> I just now started investigating this task and looking into the
>>>> options
>>>> >>> that would meet our requirements. Hope to hear from you.
>>>> >>>
>>>> >>> Regards
>>>> >>>
>>>> >>> Mauro
>>>> >>>
>>>> >>> >
>>>> >>> _______________________________________________
>>>> >>> keycloak-dev mailing list
>>>> >>> keycloak-dev at lists.jboss.org
>>>> >>> https://lists.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 yuichi.nakamura.fe at hitachi.com  Tue Mar 19 03:31:34 2019
From: yuichi.nakamura.fe at hitachi.com (=?utf-8?B?5Lit5p2R6ZuE5LiAIC8gTkFLQU1VUkHvvIxZVVVJQ0hJ?=)
Date: Tue, 19 Mar 2019 07:31:34 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
Message-ID: <TY2PR01MB45402474259C26613E0F8E76C9400@TY2PR01MB4540.jpnprd01.prod.outlook.com>

Hi,

Sorry, we have implemented only for Edge now.
Please wait for other browsers.

> One comment is that it shouldn't create a new table, but rather just serialize the value to the existing credential table in the same way as the FIDO U2F example does [1].
Thank you, we will fix.

Regards,
Yuichi Nakamura


From: Stian Thorgersen <sthorger at redhat.com> 
Sent: Monday, March 18, 2019 5:49 PM
To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>; ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com>; ???? / MOGI?TAKASHI <takashi.mogi.ep at hitachi.com>; Yoshikazu Nojima <mail at ynojima.net>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

Tried this out today and it didn't work for me. I was getting some JS error both on Chrome and Firefox when trying to register authenticator.?

One comment is that it shouldn't create a new table, but rather just serialize the value to the existing credential table in the same way as the FIDO U2F example does [1].?

[1]?https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f

On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com> wrote:
Hi, 

We?ve uploaded the initial prototype of webauthn authenticator below:? 
https://github.com/webauthn4j/keycloak-webauthn-authenticator

Feedback is welcomed.

From: Stian Thorgersen <mailto:sthorger at redhat.com> 
Sent: Thursday, February 28, 2019 6:53 PM
To: ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

That's great, thanks.

Do you have an idea on roughly when you can have a prototype ready?

On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:mailto:yuichi.nakamura.fe at hitachi.com> wrote:
Hi,

My team has begun to help webauthn4j project, 
and is going to develop prototype of authenticator for keycloak.
We'd like to take this.

Regards,
Yuichi Nakamura
Hitachi, Ltd.

-----Original Message-----
From: mailto:mailto:keycloak-dev-bounces at lists.jboss.org <mailto:mailto:keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:mailto:keycloak-dev at lists.jboss.org>
Subject: [!][keycloak-dev] Request for someone to contribute an WebAuthn4j extension

A while back I created an experimental extension to Keycloak for FIDO U2F.
It would be great if someone could adapt this to WebAuthn by leveraging webauthn4j library [1].

Any takers? It shouldn't be hard ;)

[1] https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
_______________________________________________
keycloak-dev mailing list
mailto:mailto:keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev


From h2-wada at nri.co.jp  Tue Mar 19 05:48:24 2019
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Tue, 19 Mar 2019 18:48:24 +0900
Subject: [keycloak-dev] Implementation of OAuth 2.0 Device Authorization
	Grant
Message-ID: <5C90BAE8.5080607@nri.co.jp>

Hello,

I'm interested in implementing OAuth 2.0 Device Authorization Grant [1] into Keycloak.
I found KEYCLOAK-7675 as the feature request, is there anyone already working? Also, is the pull request welcome?

The spec is still draft, but many IdPs such as Goolgle, MS, Facebook, Salesforce have already implemented it.
I believe supporting the spec will further extend the Keycloak use-case.

- [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15

Best regards,

-- 
Hiroyuki Wada (@wadahiro)
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp



From sthorger at redhat.com  Tue Mar 19 05:59:19 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Mar 2019 10:59:19 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
Message-ID: <CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>

You're right. In fact this should probably be split into two separate
authenticators. For realm limits it should be checked as a first part
(otherwise you have users authenticating and expensive password hashing
when it's already known the session won't be permitted).

For regular sessions authenticator works well, but to be honest I
completely forgot about brokering. For realm limits it's fine as that
authenticator can happen prior to the redirect, but for users there's no
hook after the redirected back from the external broker today. There's the
first login flow, but that only happens on the first time.

On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com> wrote:

> Ok, I'm missing some fundamental understanding here. Please help :)
>
> In case of the browser flow, the authentication flow is executed upon
> loading a page using the browser. At this time checks are being performed
> to see if the user is already logged on. If this is the case, no
> authentication has to be performed and the user is presented the requested
> page.
> But if the user is not yet logged on, the cookie authenticator can't do
> anything usefull resulting in the next authenticator to trigger. Eventually
> the 'browser forms' authenticator presents a login screen.
>
> Given the fact that we need to deny the user access in case a session
> already exists for his/her account on another machine, we need to know who
> this user is. How can we know which user we are dealing with at the start
> of the flow?
> I can see this working for limiting the number of sessions for each realm,
> but not for limiting sessions bound to individual user accounts.
>
>
>
> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> The authenticator should be added after the cookie authenticator, not at
>> the end. That will make it take affect for IdP logins as well. So it's a
>> matter of configuring it in two flows browser and direct grant.
>>
>> I appreciate it may not be the best usability, but I don't want to
>> introduce something special/hard-coded for this feature. A later
>> improvement could be to improve on the authentication flows. To have
>> different elements in a flow and not just executions as well as potentially
>> having some pre-flow checks that are done in all flows. I'd say this
>> approach is good enough though at least for now.
>>
>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> That is indeed one of the downsides of this approach.
>>> But can a misconfiguration of this functionality do any harm, besides
>>> some inconsistent behavior between authentication methods?
>>>
>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>
>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com> wrote:
>>>
>>>> If this is done via an authenticator wouldn't you have to make sure
>>>> that this authenticator is present (and all the same settings are
>>>> maintained) in the browser flow as well as the direct access flow as well
>>>> as the login flows for all configured identity providers? It seems like it
>>>> would be quite easy to make a mistake in that process and misconfigure
>>>> something somewhere.
>>>>
>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> I've started to create a simple proof of concept and want to check if I
>>>>> have my facts straight.
>>>>> As previously discussed this functionality should be provided by a
>>>>> custom
>>>>> Authenticator that is configured in an authentication flow.
>>>>>
>>>>> What I've done so far is:
>>>>> - Created implementations for both the Authenticator and
>>>>> AuthenticatorFactory interfaces.
>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>> desired
>>>>> configuration.
>>>>> - Perform the check if any session limits are exceeded inside the
>>>>> authenticate() method of the Authenticator class. (Any session
>>>>> invalidation
>>>>> will be performed here as well)
>>>>>
>>>>> Now, in order to use session limiting for regular username/password
>>>>> form
>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>> In our case we allow IDP logins as well. And to use this functionality
>>>>> for
>>>>> these logins, I've created a new authentication flow containing just
>>>>> this
>>>>> Authenticator. Finally this flow is selected in the 'Post login flow'
>>>>> of
>>>>> the IDP configuration.
>>>>> For both scenarios the Authenticator seems to be triggered at the right
>>>>> time and I should be able to apply the session limiting rules.
>>>>>
>>>>> Any thoughts or comments so far?
>>>>>
>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Ok, thanks for the clarification.
>>>>> >
>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com>
>>>>> > wrote:
>>>>> >
>>>>> >> It should be a pluggable part of the authentication flow and not a
>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>> authentication
>>>>> >> flow other than creating an authenticator. An authenticator doesn't
>>>>> need to
>>>>> >> provide a challenge though so it can be used in this instance.
>>>>> >>
>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >>> Hello,
>>>>> >>>
>>>>> >>> I am sending this e-mail because I have some questions regarding
>>>>> the
>>>>> >>> enhancement request that enables configurable session limiting in
>>>>> >>> Keycloak
>>>>> >>> as discussed here:
>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that
>>>>> Marc
>>>>> >>> Wijma
>>>>> >>> referred to in his comment as being available for this task is me
>>>>> btw :))
>>>>> >>>
>>>>> >>> In the comments a solution is proposed that makes use of a custom
>>>>> >>> Authenticator that is dropped into the authentication flow where
>>>>> it can
>>>>> >>> be
>>>>> >>> configured. While I can see the benefit of leveraging the existing
>>>>> >>> components as much as possible (including the configuration
>>>>> options in
>>>>> >>> that
>>>>> >>> flow), I am wondering if this is the best solution. As far as I
>>>>> can tell,
>>>>> >>> this component is not performing any authentication at all.
>>>>> Moreover this
>>>>> >>> functionality operates 'above' the authentication mechanisms and
>>>>> should
>>>>> >>> apply to all of them.
>>>>> >>> So is an Authenticator really the desired place to implement this?
>>>>> Or is
>>>>> >>> this just the quickest route, while not being the most desirable
>>>>> option
>>>>> >>> for
>>>>> >>> the long term? What would be an alternative approach be? That
>>>>> would place
>>>>> >>> this implementation and configuration in the existing Session
>>>>> >>> configuration
>>>>> >>> code for instance.
>>>>> >>>
>>>>> >>> I just now started investigating this task and looking into the
>>>>> options
>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>> >>>
>>>>> >>> Regards
>>>>> >>>
>>>>> >>> Mauro
>>>>> >>>
>>>>> >>> >
>>>>> >>> _______________________________________________
>>>>> >>> keycloak-dev mailing list
>>>>> >>> keycloak-dev at lists.jboss.org
>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> >>>
>>>>> >>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From sthorger at redhat.com  Tue Mar 19 08:08:49 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Mar 2019 13:08:49 +0100
Subject: [keycloak-dev] Implementation of OAuth 2.0 Device Authorization
	Grant
In-Reply-To: <5C90BAE8.5080607@nri.co.jp>
References: <5C90BAE8.5080607@nri.co.jp>
Message-ID: <CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>

In general I would welcome a contribution for this specification. I would
suggest starting with a design proposal [1] so we can discuss how it would
look like for Keycloak. As we don't have any plans on the immediate roadmap
for this a contribution would have to be a complete implementation of the
specification, include sufficient level of documentation and testing.

[1] https://github.com/keycloak/keycloak-community/tree/master/design

On Tue, 19 Mar 2019 at 10:59, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:

> Hello,
>
> I'm interested in implementing OAuth 2.0 Device Authorization Grant [1]
> into Keycloak.
> I found KEYCLOAK-7675 as the feature request, is there anyone already
> working? Also, is the pull request welcome?
>
> The spec is still draft, but many IdPs such as Goolgle, MS, Facebook,
> Salesforce have already implemented it.
> I believe supporting the spec will further extend the Keycloak use-case.
>
> - [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15
>
> Best regards,
>
> --
> Hiroyuki Wada (@wadahiro)
> Nomura Research Institute, Ltd.
> h2-wada at nri.co.jp
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Mar 19 08:17:15 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Mar 2019 13:17:15 +0100
Subject: [keycloak-dev] Implementation of OAuth 2.0 Device Authorization
	Grant
In-Reply-To: <CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>
References: <5C90BAE8.5080607@nri.co.jp>
	<CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>
Message-ID: <CAJgngAdOQHHjv0okA1GzsWs1+LnFwCLsPyGHGgLfd051s3Gp6A@mail.gmail.com>

I haven't had a deep dive into OpenID Connect Client initiated Backchannel
Authentication Flow  yet, but it raises a question if we should support
both, or just one of these specifications as they seem to be targetting
mostly the same use-cases.

On Tue, 19 Mar 2019 at 13:08, Stian Thorgersen <sthorger at redhat.com> wrote:

> In general I would welcome a contribution for this specification. I would
> suggest starting with a design proposal [1] so we can discuss how it would
> look like for Keycloak. As we don't have any plans on the immediate roadmap
> for this a contribution would have to be a complete implementation of the
> specification, include sufficient level of documentation and testing.
>
> [1] https://github.com/keycloak/keycloak-community/tree/master/design
>
> On Tue, 19 Mar 2019 at 10:59, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>
>> Hello,
>>
>> I'm interested in implementing OAuth 2.0 Device Authorization Grant [1]
>> into Keycloak.
>> I found KEYCLOAK-7675 as the feature request, is there anyone already
>> working? Also, is the pull request welcome?
>>
>> The spec is still draft, but many IdPs such as Goolgle, MS, Facebook,
>> Salesforce have already implemented it.
>> I believe supporting the spec will further extend the Keycloak use-case.
>>
>> - [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15
>>
>> Best regards,
>>
>> --
>> Hiroyuki Wada (@wadahiro)
>> Nomura Research Institute, Ltd.
>> h2-wada at nri.co.jp
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From psilva at redhat.com  Tue Mar 19 08:29:16 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 19 Mar 2019 09:29:16 -0300
Subject: [keycloak-dev] Implementation of OAuth 2.0 Device Authorization
	Grant
In-Reply-To: <CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>
References: <5C90BAE8.5080607@nri.co.jp>
	<CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>
Message-ID: <CAJrcDBeL+im0rBxt7wvMNmYwvckVrtxdODXcbdD7zamydWaRFg@mail.gmail.com>

This can also be useful in the future if we decide to improve our IoT story
and a future ACE [1] implementation.

[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-22

On Tue, Mar 19, 2019 at 9:18 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> In general I would welcome a contribution for this specification. I would
> suggest starting with a design proposal [1] so we can discuss how it would
> look like for Keycloak. As we don't have any plans on the immediate roadmap
> for this a contribution would have to be a complete implementation of the
> specification, include sufficient level of documentation and testing.
>
> [1] https://github.com/keycloak/keycloak-community/tree/master/design
>
> On Tue, 19 Mar 2019 at 10:59, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>
> > Hello,
> >
> > I'm interested in implementing OAuth 2.0 Device Authorization Grant [1]
> > into Keycloak.
> > I found KEYCLOAK-7675 as the feature request, is there anyone already
> > working? Also, is the pull request welcome?
> >
> > The spec is still draft, but many IdPs such as Goolgle, MS, Facebook,
> > Salesforce have already implemented it.
> > I believe supporting the spec will further extend the Keycloak use-case.
> >
> > - [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15
> >
> > Best regards,
> >
> > --
> > Hiroyuki Wada (@wadahiro)
> > Nomura Research Institute, Ltd.
> > h2-wada at nri.co.jp
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.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 h2-wada at nri.co.jp  Tue Mar 19 09:27:28 2019
From: h2-wada at nri.co.jp (Hiroyuki Wada)
Date: Tue, 19 Mar 2019 22:27:28 +0900
Subject: [keycloak-dev] Implementation of OAuth 2.0 Device Authorization
 Grant
In-Reply-To: <CAJgngAdOQHHjv0okA1GzsWs1+LnFwCLsPyGHGgLfd051s3Gp6A@mail.gmail.com>
References: <5C90BAE8.5080607@nri.co.jp>
	<CAJgngAeORezcK4O6mytg7khpomwiatBpXMbbQ-0Gv3y9xtLyLg@mail.gmail.com>
	<CAJgngAdOQHHjv0okA1GzsWs1+LnFwCLsPyGHGgLfd051s3Gp6A@mail.gmail.com>
Message-ID: <5C90EE40.1080901@nri.co.jp>

Thank you for your comment.

I understand, I'll write the design proposal!

> I haven't had a deep dive into OpenID Connect Client initiated Backchannel
> Authentication Flow  yet, but it raises a question if we should support
> both, or just one of these specifications as they seem to be targetting
> mostly the same use-cases.

I think there are some differences in the use cases applied.
OAuth2 Device Grant is applied for the devices with no browser or limited input capability.
Also the device does not need to know the end-user when starting the authorization flow.

OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA) is for different use-case.
CIBA is that the client is not under the control of the end-user and it can be physically separated from the authentication device.
For example, there is an identity verification case like KYC which a client is running a computer of a person working in a call center,
and an end-user authenticates with own smartphone at hand and federate it to the client when identifying with a phone call.

It is most ideal to support both specifications in Keycloak, but I would like to start the simpler specification OAuth2 Device Grant first.

Best regards,


> On Tue, 19 Mar 2019 at 13:08, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> In general I would welcome a contribution for this specification. I would
>> suggest starting with a design proposal [1] so we can discuss how it would
>> look like for Keycloak. As we don't have any plans on the immediate roadmap
>> for this a contribution would have to be a complete implementation of the
>> specification, include sufficient level of documentation and testing.
>>
>> [1] https://github.com/keycloak/keycloak-community/tree/master/design
>>
>> On Tue, 19 Mar 2019 at 10:59, Hiroyuki Wada <h2-wada at nri.co.jp> wrote:
>>
>>> Hello,
>>>
>>> I'm interested in implementing OAuth 2.0 Device Authorization Grant [1]
>>> into Keycloak.
>>> I found KEYCLOAK-7675 as the feature request, is there anyone already
>>> working? Also, is the pull request welcome?
>>>
>>> The spec is still draft, but many IdPs such as Goolgle, MS, Facebook,
>>> Salesforce have already implemented it.
>>> I believe supporting the spec will further extend the Keycloak use-case.
>>>
>>> - [1] https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15
>>>
>>> Best regards,
>>>
>>> --
>>> Hiroyuki Wada (@wadahiro)
>>> Nomura Research Institute, Ltd.
>>> h2-wada at nri.co.jp
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

-- 
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada at nri.co.jp

--------------------------------------------------------------------
??????????????????????????????????
????????????????????????????????
????????????????????????????
PLEASE READ:This e-mail is confidential and intended for
the named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
--------------------------------------------------------------------


From luke at code-house.org  Tue Mar 19 11:30:25 2019
From: luke at code-house.org (=?UTF-8?Q?=c5=81ukasz_Dywicki?=)
Date: Tue, 19 Mar 2019 16:30:25 +0100
Subject: [keycloak-dev] Microservice-oriented Integration Testing
In-Reply-To: <CAJgngAeptqcohT24vzcKT9e0+be5Tf5uDb1T+1eTJ+1i-JRmCw@mail.gmail.com>
References: <1862713637.7709667.1552064701102.JavaMail.zimbra@redhat.com>
	<1153988688.7729856.1552074311588.JavaMail.zimbra@redhat.com>
	<CAJgngAeptqcohT24vzcKT9e0+be5Tf5uDb1T+1eTJ+1i-JRmCw@mail.gmail.com>
Message-ID: <04cace51-bcbb-fa98-44c0-abffec655f60@code-house.org>

I can share my own thoughts on this as I been working on custom tests on
top of Keycloak and it turned out to be a non trivial task.

Few thoughts on this:
- Keycloak testsuite is not available in separate JAR/module, meaning it
can not be included in 3rd party projects as test framework. From maven
perspective my project would need to depend on keycloak test suite
"test-jar" which is not published in maven central. It is also kind of
anti-pattern.
- Setting up Arquillian separatelly with all its dependencies is
nightmare. Yes, there are several components which bring incompatible
core and 2-3 extra version placeholders to manage.

These are my findings which I suffered. I would really love at least
move of testsuite framework to its own module so it can be references as
first class citizen.
AbstractKeycloakTest should be part of src/main/java somewhere and get
imported into arquillian tests as test scoped dependency. Separating a
test framework will help keeping tests separated from specifics needed
to setup things.

I had an attempt with Arquillian Cube and Docker, however it has severe
issues when dependencies include a jaxrs provider other than Jersey.
Later one is used by docker client. Pulling in resteasy together with
Keycloak dependencies simply blows ups internals. I believe there is a
future in it, but couldn't pay for it just yet.

Kind regards,
?ukasz


On 11.03.2019 09:39, Stian Thorgersen wrote:
> In general it's a good idea and it can probably be done in stages rather
> than as one big task.
> 
> Could be something like:
> 
> 1. Run browser on a separate node. This could allow testing multiple
> browsers concurrently with the same Keycloak server. Perhaps we could
> create separate realms for each browser in order to allow them to run
> concurrently.
> 2. Adapter tests. These should just provision a Keycloak server somehow in
> a similar fashion to how we consume a DB from the server tests as we are
> testing the adapter not the server here. Running two side-by-side in
> Arquillian doesn't make all that much sense.
> 3. Allow tests to run separately to server. This will be required to allow
> using the testsuite on Keycloak running on Docker or OpenShift.
> 
> On Fri, 8 Mar 2019 at 20:47, Tomas Kyjovsky <tkyjovsk at redhat.com> wrote:
> 
>> I have some ideas about a possible future direction of the testsuite. I
>> wanted to kick off a discussion around this topic and see what others think.
>>
>> In context of the microservice paradigm our current approach to
>> integration testing seems a bit monolithic.
>> We run the whole testsuite on a single "all-in-one" host, while a typical
>> SSO use case always involves interaction of at least 3 separate entities
>> spread across different hosts, talking to each other via network.
>>
>> 1) SSO server
>>   + server-side integrations: JPA/cache server, LDAP server, external IDP,
>> etc.
>>   + possible clustering/scaling/failover/upgrade scenarios
>> 2) SSO client (secured service)
>>   + multiple different services, different runtimes
>>   + possibly clustered
>> 3) SSO user (delegated by user agent / browser)
>>
>> The all-in-one approach still works, and it's perhaps better for local
>> development-testing loop, but it's just a bit weird in proper integration
>> testing that for example browser (in UI compatibility tests) runs on the
>> same machine with the server and all the other services. I've been
>> wondering if it's worth pushing for a more microservice-oriented approach
>> with proper service decomposition.
>>
>> More detailed service decomposition here, feel free to add comments on it:
>> [1].
>>
>> Advatanges:
>> - more realistic setup
>> - issues which don't appear when testing on a single host can be discovered
>> - different setups on server / client / user side can be provisioned and
>> combined independently
>> - the test machine itself could be reduced to git + one JDK + Maven +
>> cloud client tools (e.g. docker, novaclient, etc.)
>> - ... anything else?
>>
>> Disadvantages:
>> - additional work, unclear how much
>> - increased complexity, a different set of challenges related to
>> provisioning (but with local docker not that much)
>> - needs preparation/configuration of VM images for all tested services
>> - not sure right now how we would handle some corner cases like service
>> restarts/reconfigs which are needed for some tests
>> - some tests might have to be rewritten/adapted to the non-localhost
>> environment
>> - ... anything else?
>>
>> Options:
>> - docker / podman
>> - openshift / kubernetes
>> - openstack, aws or similar cloud
>> - a combination of the above?
>>
>> In general the process would look like this: build project --> build
>> distro zips --> build VM images --> run tests while the testsuite itself
>> would be able to provision and teardown the tested system (or its
>> individual components) from the pre-built images. We already use something
>> like this in the performance testsuite (docker + docker compose). Maybe it
>> could be generalized to the whole testsuite.
>>
>> Since the integration testsuite already uses Arquillian I think that the
>> Arquillian Cube extension [2] would be an obvious candidate because it
>> supports both Docker (incl. the Compose orchestration format) and
>> Kubernetes/Openshift cluster (need to investigate extent of support). While
>> also keeping the default JVM-embedded test mode for development.
>>
>> For additional separation, we could also start using the remote Webdriver
>> mode instead being tied to the browser installed locally on the test
>> machine. Arquillian is able send commands to a remote Selenium Grid [3]
>> which has a bunch of independent browser nodes and relay the commands. The
>> grid is provisioned separately, and there is already some automation for it
>> in docker [4]. (I already did a quick test a while ago. There were some
>> minor issues but with some effort I think it could work.)
>>
>> Some ideas to think about. Let me  know what you think, or if you have
>> some other ideas/solutions related to this topic.
>>
>>
>> Tomas
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JEgcmaR3AiTQ/
>> [2] http://arquillian.org/arquillian-cube/
>> [3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
>> [4] https://github.com/SeleniumHQ/docker-selenium
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.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 maurodewit at gmail.com  Wed Mar 20 07:38:25 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Wed, 20 Mar 2019 12:38:25 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
Message-ID: <CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>

Isn't the 'Post login flow' in the IDP configuration the place for this? Or
do we want to avoid this since this is triggered after authentication is
complete and the session in created.
If this is the case, can you point me in the right direction to create a
hook into the redirect from the external broker?

On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com> wrote:

> You're right. In fact this should probably be split into two separate
> authenticators. For realm limits it should be checked as a first part
> (otherwise you have users authenticating and expensive password hashing
> when it's already known the session won't be permitted).
>
> For regular sessions authenticator works well, but to be honest I
> completely forgot about brokering. For realm limits it's fine as that
> authenticator can happen prior to the redirect, but for users there's no
> hook after the redirected back from the external broker today. There's the
> first login flow, but that only happens on the first time.
>
> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> Ok, I'm missing some fundamental understanding here. Please help :)
>>
>> In case of the browser flow, the authentication flow is executed upon
>> loading a page using the browser. At this time checks are being performed
>> to see if the user is already logged on. If this is the case, no
>> authentication has to be performed and the user is presented the requested
>> page.
>> But if the user is not yet logged on, the cookie authenticator can't do
>> anything usefull resulting in the next authenticator to trigger. Eventually
>> the 'browser forms' authenticator presents a login screen.
>>
>> Given the fact that we need to deny the user access in case a session
>> already exists for his/her account on another machine, we need to know who
>> this user is. How can we know which user we are dealing with at the start
>> of the flow?
>> I can see this working for limiting the number of sessions for each
>> realm, but not for limiting sessions bound to individual user accounts.
>>
>>
>>
>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> The authenticator should be added after the cookie authenticator, not at
>>> the end. That will make it take affect for IdP logins as well. So it's a
>>> matter of configuring it in two flows browser and direct grant.
>>>
>>> I appreciate it may not be the best usability, but I don't want to
>>> introduce something special/hard-coded for this feature. A later
>>> improvement could be to improve on the authentication flows. To have
>>> different elements in a flow and not just executions as well as potentially
>>> having some pre-flow checks that are done in all flows. I'd say this
>>> approach is good enough though at least for now.
>>>
>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com> wrote:
>>>
>>>> That is indeed one of the downsides of this approach.
>>>> But can a misconfiguration of this functionality do any harm, besides
>>>> some inconsistent behavior between authentication methods?
>>>>
>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>
>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>> wrote:
>>>>
>>>>> If this is done via an authenticator wouldn't you have to make sure
>>>>> that this authenticator is present (and all the same settings are
>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>> as the login flows for all configured identity providers? It seems like it
>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>> something somewhere.
>>>>>
>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I've started to create a simple proof of concept and want to check if
>>>>>> I
>>>>>> have my facts straight.
>>>>>> As previously discussed this functionality should be provided by a
>>>>>> custom
>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>
>>>>>> What I've done so far is:
>>>>>> - Created implementations for both the Authenticator and
>>>>>> AuthenticatorFactory interfaces.
>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>> desired
>>>>>> configuration.
>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>> invalidation
>>>>>> will be performed here as well)
>>>>>>
>>>>>> Now, in order to use session limiting for regular username/password
>>>>>> form
>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>> functionality for
>>>>>> these logins, I've created a new authentication flow containing just
>>>>>> this
>>>>>> Authenticator. Finally this flow is selected in the 'Post login flow'
>>>>>> of
>>>>>> the IDP configuration.
>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>> right
>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>
>>>>>> Any thoughts or comments so far?
>>>>>>
>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Ok, thanks for the clarification.
>>>>>> >
>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger at redhat.com
>>>>>> >
>>>>>> > wrote:
>>>>>> >
>>>>>> >> It should be a pluggable part of the authentication flow and not a
>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>> authentication
>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>> doesn't need to
>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>> >>
>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >>> Hello,
>>>>>> >>>
>>>>>> >>> I am sending this e-mail because I have some questions regarding
>>>>>> the
>>>>>> >>> enhancement request that enables configurable session limiting in
>>>>>> >>> Keycloak
>>>>>> >>> as discussed here:
>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that
>>>>>> Marc
>>>>>> >>> Wijma
>>>>>> >>> referred to in his comment as being available for this task is me
>>>>>> btw :))
>>>>>> >>>
>>>>>> >>> In the comments a solution is proposed that makes use of a custom
>>>>>> >>> Authenticator that is dropped into the authentication flow where
>>>>>> it can
>>>>>> >>> be
>>>>>> >>> configured. While I can see the benefit of leveraging the existing
>>>>>> >>> components as much as possible (including the configuration
>>>>>> options in
>>>>>> >>> that
>>>>>> >>> flow), I am wondering if this is the best solution. As far as I
>>>>>> can tell,
>>>>>> >>> this component is not performing any authentication at all.
>>>>>> Moreover this
>>>>>> >>> functionality operates 'above' the authentication mechanisms and
>>>>>> should
>>>>>> >>> apply to all of them.
>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>> this? Or is
>>>>>> >>> this just the quickest route, while not being the most desirable
>>>>>> option
>>>>>> >>> for
>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>> would place
>>>>>> >>> this implementation and configuration in the existing Session
>>>>>> >>> configuration
>>>>>> >>> code for instance.
>>>>>> >>>
>>>>>> >>> I just now started investigating this task and looking into the
>>>>>> options
>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>> >>>
>>>>>> >>> Regards
>>>>>> >>>
>>>>>> >>> Mauro
>>>>>> >>>
>>>>>> >>> >
>>>>>> >>> _______________________________________________
>>>>>> >>> keycloak-dev mailing list
>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> >>>
>>>>>> >>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>

From sthorger at redhat.com  Wed Mar 20 07:50:56 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Mar 2019 12:50:56 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
Message-ID: <CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>

I wasn't even aware we had the 'Post Login Flow'.

>From the description I would think that Post Login Flow is being executed
before the user session is created, while there's an authentication
session. So should be fine.

Marek - can you confirm?

On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com> wrote:

> Isn't the 'Post login flow' in the IDP configuration the place for this?
> Or do we want to avoid this since this is triggered after authentication is
> complete and the session in created.
> If this is the case, can you point me in the right direction to create a
> hook into the redirect from the external broker?
>
> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> You're right. In fact this should probably be split into two separate
>> authenticators. For realm limits it should be checked as a first part
>> (otherwise you have users authenticating and expensive password hashing
>> when it's already known the session won't be permitted).
>>
>> For regular sessions authenticator works well, but to be honest I
>> completely forgot about brokering. For realm limits it's fine as that
>> authenticator can happen prior to the redirect, but for users there's no
>> hook after the redirected back from the external broker today. There's the
>> first login flow, but that only happens on the first time.
>>
>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>
>>> In case of the browser flow, the authentication flow is executed upon
>>> loading a page using the browser. At this time checks are being performed
>>> to see if the user is already logged on. If this is the case, no
>>> authentication has to be performed and the user is presented the requested
>>> page.
>>> But if the user is not yet logged on, the cookie authenticator can't do
>>> anything usefull resulting in the next authenticator to trigger. Eventually
>>> the 'browser forms' authenticator presents a login screen.
>>>
>>> Given the fact that we need to deny the user access in case a session
>>> already exists for his/her account on another machine, we need to know who
>>> this user is. How can we know which user we are dealing with at the start
>>> of the flow?
>>> I can see this working for limiting the number of sessions for each
>>> realm, but not for limiting sessions bound to individual user accounts.
>>>
>>>
>>>
>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> The authenticator should be added after the cookie authenticator, not
>>>> at the end. That will make it take affect for IdP logins as well. So it's a
>>>> matter of configuring it in two flows browser and direct grant.
>>>>
>>>> I appreciate it may not be the best usability, but I don't want to
>>>> introduce something special/hard-coded for this feature. A later
>>>> improvement could be to improve on the authentication flows. To have
>>>> different elements in a flow and not just executions as well as potentially
>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>> approach is good enough though at least for now.
>>>>
>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> That is indeed one of the downsides of this approach.
>>>>> But can a misconfiguration of this functionality do any harm, besides
>>>>> some inconsistent behavior between authentication methods?
>>>>>
>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>
>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> If this is done via an authenticator wouldn't you have to make sure
>>>>>> that this authenticator is present (and all the same settings are
>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>> something somewhere.
>>>>>>
>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I've started to create a simple proof of concept and want to check
>>>>>>> if I
>>>>>>> have my facts straight.
>>>>>>> As previously discussed this functionality should be provided by a
>>>>>>> custom
>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>
>>>>>>> What I've done so far is:
>>>>>>> - Created implementations for both the Authenticator and
>>>>>>> AuthenticatorFactory interfaces.
>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>> desired
>>>>>>> configuration.
>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>> invalidation
>>>>>>> will be performed here as well)
>>>>>>>
>>>>>>> Now, in order to use session limiting for regular username/password
>>>>>>> form
>>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>> functionality for
>>>>>>> these logins, I've created a new authentication flow containing just
>>>>>>> this
>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>> flow' of
>>>>>>> the IDP configuration.
>>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>>> right
>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>
>>>>>>> Any thoughts or comments so far?
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Ok, thanks for the clarification.
>>>>>>> >
>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>> sthorger at redhat.com>
>>>>>>> > wrote:
>>>>>>> >
>>>>>>> >> It should be a pluggable part of the authentication flow and not a
>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>> authentication
>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>> doesn't need to
>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>> >>
>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >>> Hello,
>>>>>>> >>>
>>>>>>> >>> I am sending this e-mail because I have some questions regarding
>>>>>>> the
>>>>>>> >>> enhancement request that enables configurable session limiting in
>>>>>>> >>> Keycloak
>>>>>>> >>> as discussed here:
>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>> that Marc
>>>>>>> >>> Wijma
>>>>>>> >>> referred to in his comment as being available for this task is
>>>>>>> me btw :))
>>>>>>> >>>
>>>>>>> >>> In the comments a solution is proposed that makes use of a custom
>>>>>>> >>> Authenticator that is dropped into the authentication flow where
>>>>>>> it can
>>>>>>> >>> be
>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>> existing
>>>>>>> >>> components as much as possible (including the configuration
>>>>>>> options in
>>>>>>> >>> that
>>>>>>> >>> flow), I am wondering if this is the best solution. As far as I
>>>>>>> can tell,
>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>> Moreover this
>>>>>>> >>> functionality operates 'above' the authentication mechanisms and
>>>>>>> should
>>>>>>> >>> apply to all of them.
>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>> this? Or is
>>>>>>> >>> this just the quickest route, while not being the most desirable
>>>>>>> option
>>>>>>> >>> for
>>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>>> would place
>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>> >>> configuration
>>>>>>> >>> code for instance.
>>>>>>> >>>
>>>>>>> >>> I just now started investigating this task and looking into the
>>>>>>> options
>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>> >>>
>>>>>>> >>> Regards
>>>>>>> >>>
>>>>>>> >>> Mauro
>>>>>>> >>>
>>>>>>> >>> >
>>>>>>> >>> _______________________________________________
>>>>>>> >>> keycloak-dev mailing list
>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> >>>
>>>>>>> >>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>

From sthorger at redhat.com  Wed Mar 20 08:00:39 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Mar 2019 13:00:39 +0100
Subject: [keycloak-dev] W3C Web Authentication - Two-Factor,
	implementing JIRAs
In-Reply-To: <685b12117e024c449ae6e1a4e221cac8@elca.ch>
References: <24cbd52475494e4a95f9282a280d8fde@elca.ch>
	<CAJgngAcWrTfp7-w_CX7GooohArQe62xp78+58oGCQozPmjojXw@mail.gmail.com>
	<111481de90e245cabb85e75fa4f72c70@elca.ch>
	<CAJgngAeqsgQGRnHwS38SLhtxJKgn+ADRktZ1243GAD7KtjB+Dg@mail.gmail.com>
	<685b12117e024c449ae6e1a4e221cac8@elca.ch>
Message-ID: <CAJgngAeRE3ExFY469n_PURpHEnduVgiBuuNGmMOHP0SYYunVPA@mail.gmail.com>

On Mon, 18 Mar 2019 at 10:51, Doswald Alistair <alistair.doswald at elca.ch>
wrote:

> * I can move the design proposal to
> https://github.com/keycloak/keycloak-community/tree/master/design. For
> this I simply format in Markdown and do a pull request?
>

Yes


>
>
> * I?d also be in favour of a face to face meeting. I?m in the CET timezone
> (currently GMT+1 and GMT+2 from the 31st of march). This week I?d be
> available Tuesday, Thursday and Friday, and I also have availabilities next
> week (except Monday). I?m not sure of the logistics however? We use skype
> for business internally, but maybe you have a preferred platform? Also,
> would you mind if one of my colleagues who could work on the JIRAs joins
> the meeting call?
>

I've had issues with Skype in the past. We can use BlueJeans if that works
for you? Tuesday at 12?


> * Since I?m answering anyway, I?ll answer a few of your comments (the rest
> can be discussed later as I think that they are more technical):
>
>
>
> - I believe that you?re correct to say that we should consider the step-up
> (and one of my colleagues actually had the same comment upon reading my
> proposal). I may have some ideas on how this would work with the proposed 2
> factor, but I?d like to read up on what was already discussed/proposed
> first. Has there been more discussed than what?s at
> https://issues.jboss.org/browse/KEYCLOAK-847,
> http://lists.jboss.org/pipermail/keycloak-user/2016-November/008311.html,
> http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007150.html and
> http://lists.jboss.org/pipermail/keycloak-dev/2017-April/009245.html?
>

Had a long discussion with some folks from the team a while back around
step-up, but of course we didn't write it down ;)

In summary the plans where to add markers into the flows that would be used
to set the authentication levels, then allow the authentication processor
to skip as well as fast forward as needed.


>
>
> - For the users setting their own default authenticator I agree (and
> intended to describe that in the text, though upon re-reading that part of
> the description is fragmented), as long as the admin has enabled the
> authentication category in a flow. However, it is true that between the
> default flow and custom/per-client flows it may be difficult to determine
> how the user sees/selects his preferred authenticator for an authentication
> step (not to mention what would happen when an admin changes the
> configuration). This should definitely be further detailed. I?m not sure
> yet if some extra data structures are necessary though, maybe some custom
> functions to get the required information is sufficient.
>

We need a group that means "one of these" ;)


>
>
> - I think that having a built in flow that follows the proposed logic
> isn?t too difficult. There?d be the ?Authenticated on?,
>
> ?Authentication factor 1? and ?Authentication factor 2? executions with
> some default authenticator categories. The admin would be able to set
> enabled and disabled for the built-in authenticator categories, but be able
> to add and remove in custom flows. That way a newbie admin wouldn?t be able
> to do too much damage, while a more experienced one would be able to
> customize as he wants. Some extra documentation within the admin console
> may help with this.
>
>
>
>
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* vendredi 15 mars 2019 09:25
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
>
>
> * Would be worth moving this to a design proposal on
> https://github.com/keycloak/keycloak-community/tree/master/design. Would
> be easier to work collectively on a design proposal there than to have an
> endless thread on a ML ;). I'd also be open to join you on a call to have a
> discussion "face to face"
>
>
>
> * I was thinking to limit to two factor for now, but you're probably right
> here with regards to consider the bigger picture now as it may be difficult
> to get it right otherwise
>
>
>
> * Need to consider how this fits into step-up authentication
>
>
>
> * Admins should be able to select level of authentication required, but
> users should be able to choose from available options
>
>
>
> * Users should be able to select from available mechanisms when
> configuring. Users should be able to set their own default. This means the
> account console/rest needs metadata to discover available mechanisms. I
> wonder if there's a need for something outside of flows and authenticators
> to capture metadata about supported credential types which is used by
> account and admin consoles to manage credentials.
>
>
>
> * I was aiming a simpler setup where admin doesn't need to create custom
> flow unless they want to add custom authenticators. That means
> authenticators should be enabled/disabled in the flow rather than
> added/removed
>
>
>
> Some more comments inline below
>
>
>
> On Thu, 14 Mar 2019 at 14:02, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
> This is OK for me. I propose starting with initial proposals for the
> fundamentals in this email, and once there's an agreement on those,
> separating the discussion between the two JIRAs to refine the concepts for
> each one. Once the work to be done is clearer, it can be supplemented with
> screen mockups and/or prototypes.
>
>
>
>
>
> 1) Scope of the modifications
>
>
>
> - For JIRA KEYCLOAK-9693 <https://issues.jboss.org/browse/KEYCLOAK-9693>,
> I believe that the description in the JIRA is not general enough to cover
> the description in web-authn-two-factor.md
> <https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md>
> . Modifications to the authentication flows should support single factor,
> as well as 2nd factor and allow both authentication factor levels to select
> the alternative types of authenticator to be used. This allows a single
> factor authentication to use for example a FIDO2 dongle for passwordless
> authentication, or even let the user choose between the dongle and a
> password during the login.  Modifications for this JIRA include: changes to
> the authentication logic, changes to the authentication part of the admin
> console, changes to the authentication screens that the user sees during
> login, changes to the REST API, and possibly some changes to the database.
>
>
>
> In the first round we are focusing on two factor. Follow-up later is
> passwordless flows for web-authn. Passwordless is more tricky as it
> requires identity first login flow, ability for users to somehow define how
> they authenticate, rather than just what the second factor is, ability for
> admins to define authentication optoins rather than just two factor options.
>
>
>
> As I mentioned above though it is probably all to linked to consider only
> one at the design phase. So perhaps we need to work together on a design
> proposal that will include everything including step-up authentication.
>
>
>
>
>
> - For JIRA KEYCLOAK-9694 <https://issues.jboss.org/browse/KEYCLOAK-9694>,
> changes are to the "users > credentials" part of the administration console
> and to the REST API.
>
>
>
>
>
> 2) Design proposal for KEYCLOAK-9693
> <https://issues.jboss.org/browse/KEYCLOAK-9693>
>
>
>
> a) Authentication logic
>
>
>
> The current authentication flow system should be kept, but perhaps
> simplified. For a start I think that actual authenticators categories -
> that is elements that provide identity (e.g. password, cookie, kerberos,
> otp, fido, ...) - should be separate from other executions like "reset
> password".
>
>
>
> Thus, instead of directly adding "cookie" or "password" as alternatives in
> the authentication flow, the user can add the execution "authentication
> factor", and under authentication factor he can add only the valid
> authenticator categories. Each of the authenticator categories under the
> authentication factor are considered valid alternatives, and are evaluated
> in order. The authentication stops being automatically evaluated at the
> first authenticator that requires user input (alternative: all non-user
> input authenticators are evaluated before the first user-input
> authenticator).
>
>
>
> Adding a 2nd "authentication factor" execution sets the 2nd factor, and it
> must then have authenticators assigned. To have an authenticator category
> be valid for both authentication factors it must be set under both 1st and
> 2nd authentication factor. For example, kerberos could be set for both 1st
> and 2nd factor, which would mean that the user skips both factors if he's
> registered with kerberos, but it could also be just set for the first
> factor, in which case he'd still have to input the 2nd factor. To handle
> optional 2nd factors there could either be a "optional authentication
> factor type" or have an "optional" flag in the options of the
> "authentication factor".
>
>
>
> Potentially, this system could also allow a company that's really security
> conscientious/paranoiac to set N factors.
>
>
>
> Authentication factors are treated as a bloc in the evaluation of
> alternatives. That is, if in a flow there's "Identity provider redirector",
> "authentication factor 1", "authentication factor 2", entering the
> authentication factor 1 flow will automatically cause "authentication
> factor 2" to be executed after.
>
>
>
> To make things perhaps a little more clear, the current default "Browser"
> authentication would become for example:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2) [OPTIONAL]
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>
>
> And if we wanted to have an mandatory 2nd factor, with either OTP or a
> FIDO2 configured:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authentication factor (1)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- Cookie
>
>   |- Kerberos
>
>   |- OTP Form
>
>   |- FIDO-2
>
>
>
> Potentially we could also introduce another type of authentication
> execution, we could call it "Authenticated on", to simplify the
> authenticators that bypass the authentication factors. We could then have:
>
>
>
> Auth type
>
> ------------------------------------------------------------
>
> Identity Provider Redirector
>
> Authenticated on
>
>   |- Cookie
>
>   |- Kerberos
>
> Authentication factor (1)
>
>   |- Username Password Form
>
> Authentication factor (2)
>
>   |- OTP Form
>
>   |- FIDO-2
>
>
>
> I like this in general. Devil is in the detail here though and need to
> think about this some more, especially how it fits into
> step-up-authentication.
>
>
>
>
>
> b) Authentication section in the admin console
>
>
>
> The schema described in a) would be implemented in the Authentication >
> flows. Bindings and Required Actions don't need any change I think. For
> policies I believe the password policy for the realm should remain, but the
> OTP policy should disappear, as a user could have several alternative OTP
> devices with different settings. As such, the information about the OTP
> settings should probably move to information associated with the credential.
>
>
>
> +1 I also think this is limited to the flow itself. Bear in mind I want to
> have a built-in flow that can be configured rather than requiring creating
> new flows. For example if we have OTP and WebAuthn authenticators an admin
> should be able to just enabled WebAuthn, not have to create a new flow to
> add it. Obviously a new custom flow would be required if the flow or custom
> authenticators are added. Moving OTP policy from realm to authenticator is
> already planned work, it was only added to the realm in the first place as
> it was done before we had configurable authenticators.
>
>
>
>
>
> c) Authentication screens for the user
>
>
>
> When the user logs in, unless he has something like a cookie he will see
> by default the first configuration interface configured in the current
> Authentication factor. If there are many different factors configured, he
> can access a list of any valid authenticator to use. If the user fails with
> the selected authenticator, he may choose another configured authenticator
> to validate the step.
>
>
>
> When it comes to default that is the users choice. So as a user if I have
> chosen webauthn as my default that should be shown first to me, even if the
> realm has the OTP as the first/default. It's also not when the user fails
> with the selected authenticator, but rather allow the user to choose a
> different authenticator.
>
>
>
>
>
> d) REST API
>
>
>
> There's no major change here, aside from updating the scheme to support
> the separation between authenticator categories and executions, and adding
> instructions to edit which authenticator categories are assigned to an
> authentication factor.
>
>
>
> e) database modifications
>
>
>
> Authenticator categories could be separated from executions either by
> having a new dedicated table, or by introducing a field in the
> authentication_execution table
>
>
>
> Realm config is responsible for most of the mess in the tables today. It's
> just plain daft to save this as separate tables/columns as it's always
> fetched as one blog and never queried. So I wonder if we could take a first
> start at this by simply storing the whole authentication flow including
> authenticator config as a single JSON blob in the DB.
>
>
>
>
>
>
>
> 3) Design proposal for KEYCLOAK-9694
> <https://issues.jboss.org/browse/KEYCLOAK-9694>
>
>
>
> a) Changes to the users > Credential menu
>
>
>
> Instead of manage Password we have "manage credentials", with a list of
> credentials for a user. The credentials grouped by type, and should
> indicate by which authentication factor they are valid for (1st factor, 2nd
> factor, unconfigured). The administrator should be able to edit / remove a
> credential.
>
>
>
> - For editing the administrator should be able to visualise the data of
> the credential (except the secret and the salt) and edit metadata about a
> device. Data would be any data in the fields of the credential that
> describe immutable data about the credential, and metadata would be for
> example label that a user can see and edit to name his device and a label
> that only the administrator could see and edit. The administrator (and
> user) should be able to set a "preferred credential" for each
> authentication factor level, which will override the factor shown by
> default during the login.
>
>
>
> - For deleting, I think that this should be linked to the authentication
> factors and authenticator categories of the realm, for example:
>
>    + For a realm with a single factor configured of types password and
> FIDO2, the credentials can be removed until ONE remains, and that last one
> cannot be removed.
>
>    + For a realm with a two factors configured, the first with password
> and FIDO2, and the second with OTP and FIDO UAF (I know, this is not a very
> good example from a security point of view), then it must be impossible to
> remove the last credential for the first factor, and to remove the last
> credential for the second factor.
>
>
>
> A note for passwords: Unlike other credentials I don't think that there
> should be more than one password that can be configured. Also, among its
> edition option it should be possible to reset (temporarily or not) as is
> currently the case.
>
>
>
> If the administrator and user can remove credentials, I do not know if the
> possibility to disable credentials is still useful. I don't see any
> problems with the feature either though, so if it?s still deemed useful it
> would keep its current behaviour.
>
>
>
> Credentials needs to have some metadata associated with them. Does it
> support a user to have mutiple (passwords is a single, webauthn is
> multiple). Can the admin update the value (passwords admin can update,
> webauthn only users can and that's through application initiated actions
> which account console will use). The thinking with regards to
> adding/updating credentials is that users do it through actions (required
> or application initiated), while admins do it directly in the console (in
> which case we need to have a dynamic way to specify the values, something
> like how component model works).
>
>
>
>
>
> b) Modifications to the REST API
>
>
>
> Currently there's no way to get credentials with the REST API. This should
> change with these modifications to reflect the new options for the
> administrator. The API should function in the same manner as the admin
> console: Credentials can be exposed (except for secret and hash values),
> the metadata edited and the credentials deleted with the same restrictions
> as described in section 3a
>
>
>
> We just need to be very careful here that secrets are never returned on a
> REST endpoint, but otherwise yes we need an endpoint that can list a users
> credentials.
>
>
>
>
>
> c) Database modifications
>
>
>
> I do not believe that this modification entails any database
> modifications. The current system with credential and credential attributes
> should be sufficient for the handling of multiple authenticators.
>
>
>
>
>
>
>
> That's it. Comments, questions and criticism are all welcome.
> ------------------------------
>
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* 08 March 2019 13:17
> *To:* Doswald Alistair
> *Cc:* keycloak-dev
> *Subject:* Re: [keycloak-dev] W3C Web Authentication - Two-Factor,
> implementing JIRAs
>
>
>
> No one is working on the admin part at the moment, so contributions here
> would be very welcome. It's not a straightforward task though and would
> need a fair bit of design/prototyping/discussions to get this right.
>
>
>
> On Fri, 8 Mar 2019 at 11:14, Doswald Alistair <alistair.doswald at elca.ch>
> wrote:
>
> Hello,
>
>
> I've been following the thread about the implementation of WebAuthn in
> Keycloak, and saw that there are some related JIRAs in the following design
> document
> https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md
> .
>
>
> Is anyone  already working on JIRAs
> https://issues.jboss.org/browse/KEYCLOAK-9693 and
> https://issues.jboss.org/browse/KEYCLOAK-9694 for managing multiple 2nd
> factor authenticators? If not, with my colleagues we could implement them
> relatively quickly as we have use cases for these functionalities.
>
>
> Best regards,
>
>
> Alistair Doswald
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From mposolda at redhat.com  Wed Mar 20 09:59:08 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 20 Mar 2019 14:59:08 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
Message-ID: <8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>

On 20/03/2019 12:50, Stian Thorgersen wrote:
> I wasn't even aware we had the 'Post Login Flow'.
>
> From the description I would think that Post Login Flow is being 
> executed before the user session is created, while there's an 
> authentication session. So should be fine.
>
> Marek - can you confirm?

Yes, exactly. User session doesn't yet exists when "Post Login Flow" is 
executed. This flow exists exactly because of use-cases like this - 
having the ability to execute the hooks after broker authentication. For 
example some people wanted to execute TOTP after the authentication with 
"facebook" broker etc.

Marek

>
> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com 
> <mailto:maurodewit at gmail.com>> wrote:
>
>     Isn't the 'Post login flow' in the IDP configuration the place for
>     this? Or do we want to avoid this since this is triggered after
>     authentication is complete and the session in created.
>     If this is?the case, can you point me in the right direction to
>     create a hook into the redirect from the external broker?
>
>     On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         You're right. In fact this should probably be split into two
>         separate authenticators. For realm limits it should be checked
>         as a first part (otherwise you have users authenticating and
>         expensive password hashing when it's already known the session
>         won't be permitted).
>
>         For regular sessions authenticator works well, but to be
>         honest I completely forgot about brokering. For realm limits
>         it's fine as that authenticator can happen prior to the
>         redirect, but for users there's no hook after the redirected
>         back from the external broker today. There's the first login
>         flow, but that only happens on the first time.
>
>         On Mon, 18 Mar 2019 at 10:59, Mauro de Wit
>         <maurodewit at gmail.com <mailto:maurodewit at gmail.com>> wrote:
>
>             Ok, I'm missing some fundamental understanding here.
>             Please help :)
>
>             In case of the browser flow, the authentication flow is
>             executed upon loading a page using the browser. At this
>             time checks are being performed to see if the user is
>             already logged on. If this is the case, no authentication
>             has to be performed and the user is presented the
>             requested page.
>             But if the user is not yet logged on, the cookie
>             authenticator can't do anything usefull resulting in the
>             next authenticator to trigger. Eventually the 'browser
>             forms' authenticator presents a login screen.
>
>             Given the fact that we need to deny the user access in
>             case a session already exists for his/her account on
>             another machine, we need to know who this user is. How can
>             we know which user we are dealing with at the start of the
>             flow?
>             I can see this working for limiting the number of sessions
>             for each realm, but not for limiting sessions bound to
>             individual user accounts.
>
>
>
>             On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen
>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>                 The authenticator should be added after the cookie
>                 authenticator, not at the end. That will make it take
>                 affect for IdP logins as well. So it's a matter of
>                 configuring it in two flows browser and direct grant.
>
>                 I appreciate it may not be the best usability, but I
>                 don't want to introduce something special/hard-coded
>                 for this feature. A later improvement could be to
>                 improve on the authentication flows. To have different
>                 elements in a flow and not just executions as well as
>                 potentially having some pre-flow checks that are done
>                 in all flows. I'd say this approach is good enough
>                 though at least for now.
>
>                 On Mon, 18 Mar 2019 at 09:00, Mauro de Wit
>                 <maurodewit at gmail.com <mailto:maurodewit at gmail.com>>
>                 wrote:
>
>                     That is indeed one of the downsides of this approach.
>                     But can a misconfiguration of this functionality
>                     do any harm, besides some inconsistent behavior
>                     between authentication methods?
>
>                     @stian at redhat.com <mailto:stian at redhat.com> any
>                     thoughts?
>
>                     On Fri, 15 Mar 2019 at 15:23, Jared Blashka
>                     <jblashka at redhat.com <mailto:jblashka at redhat.com>>
>                     wrote:
>
>                         If this is done via an authenticator wouldn't
>                         you have to make sure that this authenticator
>                         is present (and all the same settings are
>                         maintained) in the browser flow as well as the
>                         direct access flow as well as the login flows
>                         for all configured identity providers? It
>                         seems like it would be quite easy to make a
>                         mistake in that process and misconfigure
>                         something somewhere.
>
>                         On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit
>                         <maurodewit at gmail.com
>                         <mailto:maurodewit at gmail.com>> wrote:
>
>                             I've started to create a simple proof of
>                             concept and want to check if I
>                             have my facts straight.
>                             As previously discussed this functionality
>                             should be provided by a custom
>                             Authenticator that is configured in an
>                             authentication flow.
>
>                             What I've done so far is:
>                             - Created implementations for both the
>                             Authenticator and
>                             AuthenticatorFactory interfaces.
>                             - Added a set of ProviderConfigProperty
>                             instances that allow the desired
>                             configuration.
>                             - Perform the check if any session limits
>                             are exceeded inside the
>                             authenticate() method of the Authenticator
>                             class. (Any session invalidation
>                             will be performed here as well)
>
>                             Now, in order to use session limiting for
>                             regular username/password form
>                             logins, I have created a copy of the
>                             'browser flow' and added this
>                             Authenticator as a 'required' execution at
>                             the end of the flow.
>                             In our case we allow IDP logins as well.
>                             And to use this functionality for
>                             these logins, I've created a new
>                             authentication flow containing just this
>                             Authenticator. Finally this flow is
>                             selected in the 'Post login flow' of
>                             the IDP configuration.
>                             For both scenarios the Authenticator seems
>                             to be triggered at the right
>                             time and I should be able to apply the
>                             session limiting rules.
>
>                             Any thoughts or comments so far?
>
>                             On Tue, 12 Mar 2019 at 14:53, Mauro de Wit
>                             <maurodewit at gmail.com
>                             <mailto:maurodewit at gmail.com>> wrote:
>
>                             > Ok, thanks for the clarification.
>                             >
>                             > On Tue, 12 Mar 2019 at 12:39, Stian
>                             Thorgersen <sthorger at redhat.com
>                             <mailto:sthorger at redhat.com>>
>                             > wrote:
>                             >
>                             >> It should be a pluggable part of the
>                             authentication flow and not a
>                             >> hardcoded element. There is no other
>                             way to plug in to the authentication
>                             >> flow other than creating an
>                             authenticator. An authenticator doesn't
>                             need to
>                             >> provide a challenge though so it can be
>                             used in this instance.
>                             >>
>                             >> On Tue, 12 Mar 2019 at 10:57, Mauro de
>                             Wit <maurodewit at gmail.com
>                             <mailto:maurodewit at gmail.com>> wrote:
>                             >>
>                             >>> Hello,
>                             >>>
>                             >>> I am sending this e-mail because I
>                             have some questions regarding the
>                             >>> enhancement request that enables
>                             configurable session limiting in
>                             >>> Keycloak
>                             >>> as discussed here:
>                             >>>
>                             https://issues.jboss.org/browse/KEYCLOAK-849
>                             (The developer that Marc
>                             >>> Wijma
>                             >>> referred to in his comment as being
>                             available for this task is me btw :))
>                             >>>
>                             >>> In the comments a solution is proposed
>                             that makes use of a custom
>                             >>> Authenticator that is dropped into the
>                             authentication flow where it can
>                             >>> be
>                             >>> configured. While I can see the
>                             benefit of leveraging the existing
>                             >>> components as much as possible
>                             (including the configuration options in
>                             >>> that
>                             >>> flow), I am wondering if this is the
>                             best solution. As far as I can tell,
>                             >>> this component is not performing any
>                             authentication at all. Moreover this
>                             >>> functionality operates 'above' the
>                             authentication mechanisms and should
>                             >>> apply to all of them.
>                             >>> So is an Authenticator really the
>                             desired place to implement this? Or is
>                             >>> this just the quickest route, while
>                             not being the most desirable option
>                             >>> for
>                             >>> the long term? What would be an
>                             alternative approach be? That would place
>                             >>> this implementation and configuration
>                             in the existing Session
>                             >>> configuration
>                             >>> code for instance.
>                             >>>
>                             >>> I just now started investigating this
>                             task and looking into the options
>                             >>> that would meet our requirements. Hope
>                             to hear from you.
>                             >>>
>                             >>> Regards
>                             >>>
>                             >>> Mauro
>                             >>>
>                             >>> >
>                             >>>
>                             _______________________________________________
>                             >>> 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
>


From maurodewit at gmail.com  Wed Mar 20 10:00:07 2019
From: maurodewit at gmail.com (Mauro de Wit)
Date: Wed, 20 Mar 2019 15:00:07 +0100
Subject: [keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
In-Reply-To: <8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
References: <CACihWx2N0zfT2pTSgRxtQnwavwNa7CiQefQ9O=GVrwX=7YB3pQ@mail.gmail.com>
	<CACihWx2Leb4ZeuvXk778O1DLOstMexzrki=xgxmFwnN=2YJGgg@mail.gmail.com>
	<CAJgngAfsW2PoaAkZUa7V8_tZuTQW-7a7vFzSYW7f9UiP_LkqUw@mail.gmail.com>
	<CACihWx2NnqaBMUdoGuzgUBsEAR4Ltx1xNdc0Quvk-F67aHMW=Q@mail.gmail.com>
	<CACihWx1JAxGz_Zn=Q0xCsB=T9wvDiEBwn6oB=pcooV6TP7NZqw@mail.gmail.com>
	<CALO-DfAoZpdzweZyx1iBXK=nU3XGqDpjgE8202QDJOraTFaYJQ@mail.gmail.com>
	<CACihWx2SWcXqq=gy+X3U=Ct0o2E+zaVAKpH-ahJS88+E64AqRQ@mail.gmail.com>
	<CAJgngAfJ2pgUgLBu2gXnmxrdicFzigPgfG=G4yudsPgz82pcZg@mail.gmail.com>
	<CACihWx2fi+tpT57grJ85pRdrj36f0cuvsErwoQUdSkUQeVrJOQ@mail.gmail.com>
	<CAJgngAdOEEAb4yAn4j=0aXE2=4fnjB8yMck8Yw4=88+SqRzvRw@mail.gmail.com>
	<CACihWx3Pk+_1Nbi+9uzvH1VchZCbf3rJi5sMvcHnCGMnD6Y8DA@mail.gmail.com>
	<CAJgngAduexRmVouqoYnEnmD-Lba5quKAZ5gC4dO7cBFM9kChqA@mail.gmail.com>
	<8d3aaed6-f878-ac5e-0132-0ceae2934471@redhat.com>
Message-ID: <CACihWx1WDLS56OWvW7ppMVBPG8aiy0RhaL_N1K21ZZTLOkTCdA@mail.gmail.com>

Makes sense. Thanks for the input guys.
I'm on the right track then :)

On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:

> On 20/03/2019 12:50, Stian Thorgersen wrote:
>
> I wasn't even aware we had the 'Post Login Flow'.
>
> From the description I would think that Post Login Flow is being executed
> before the user session is created, while there's an authentication
> session. So should be fine.
>
> Marek - can you confirm?
>
> Yes, exactly. User session doesn't yet exists when "Post Login Flow" is
> executed. This flow exists exactly because of use-cases like this - having
> the ability to execute the hooks after broker authentication. For example
> some people wanted to execute TOTP after the authentication with "facebook"
> broker etc.
>
> Marek
>
>
> On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com> wrote:
>
>> Isn't the 'Post login flow' in the IDP configuration the place for this?
>> Or do we want to avoid this since this is triggered after authentication is
>> complete and the session in created.
>> If this is the case, can you point me in the right direction to create a
>> hook into the redirect from the external broker?
>>
>> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> You're right. In fact this should probably be split into two separate
>>> authenticators. For realm limits it should be checked as a first part
>>> (otherwise you have users authenticating and expensive password hashing
>>> when it's already known the session won't be permitted).
>>>
>>> For regular sessions authenticator works well, but to be honest I
>>> completely forgot about brokering. For realm limits it's fine as that
>>> authenticator can happen prior to the redirect, but for users there's no
>>> hook after the redirected back from the external broker today. There's the
>>> first login flow, but that only happens on the first time.
>>>
>>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com> wrote:
>>>
>>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>>
>>>> In case of the browser flow, the authentication flow is executed upon
>>>> loading a page using the browser. At this time checks are being performed
>>>> to see if the user is already logged on. If this is the case, no
>>>> authentication has to be performed and the user is presented the requested
>>>> page.
>>>> But if the user is not yet logged on, the cookie authenticator can't do
>>>> anything usefull resulting in the next authenticator to trigger. Eventually
>>>> the 'browser forms' authenticator presents a login screen.
>>>>
>>>> Given the fact that we need to deny the user access in case a session
>>>> already exists for his/her account on another machine, we need to know who
>>>> this user is. How can we know which user we are dealing with at the start
>>>> of the flow?
>>>> I can see this working for limiting the number of sessions for each
>>>> realm, but not for limiting sessions bound to individual user accounts.
>>>>
>>>>
>>>>
>>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> The authenticator should be added after the cookie authenticator, not
>>>>> at the end. That will make it take affect for IdP logins as well. So it's a
>>>>> matter of configuring it in two flows browser and direct grant.
>>>>>
>>>>> I appreciate it may not be the best usability, but I don't want to
>>>>> introduce something special/hard-coded for this feature. A later
>>>>> improvement could be to improve on the authentication flows. To have
>>>>> different elements in a flow and not just executions as well as potentially
>>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>>> approach is good enough though at least for now.
>>>>>
>>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> That is indeed one of the downsides of this approach.
>>>>>> But can a misconfiguration of this functionality do any harm, besides
>>>>>> some inconsistent behavior between authentication methods?
>>>>>>
>>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>>
>>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> If this is done via an authenticator wouldn't you have to make sure
>>>>>>> that this authenticator is present (and all the same settings are
>>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>>> something somewhere.
>>>>>>>
>>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I've started to create a simple proof of concept and want to check
>>>>>>>> if I
>>>>>>>> have my facts straight.
>>>>>>>> As previously discussed this functionality should be provided by a
>>>>>>>> custom
>>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>>
>>>>>>>> What I've done so far is:
>>>>>>>> - Created implementations for both the Authenticator and
>>>>>>>> AuthenticatorFactory interfaces.
>>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>>> desired
>>>>>>>> configuration.
>>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>>> invalidation
>>>>>>>> will be performed here as well)
>>>>>>>>
>>>>>>>> Now, in order to use session limiting for regular username/password
>>>>>>>> form
>>>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>>> functionality for
>>>>>>>> these logins, I've created a new authentication flow containing
>>>>>>>> just this
>>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>>> flow' of
>>>>>>>> the IDP configuration.
>>>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>>>> right
>>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>>
>>>>>>>> Any thoughts or comments so far?
>>>>>>>>
>>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Ok, thanks for the clarification.
>>>>>>>> >
>>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>>> sthorger at redhat.com>
>>>>>>>> > wrote:
>>>>>>>> >
>>>>>>>> >> It should be a pluggable part of the authentication flow and not
>>>>>>>> a
>>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>>> authentication
>>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>>> doesn't need to
>>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>>> >>
>>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >>> Hello,
>>>>>>>> >>>
>>>>>>>> >>> I am sending this e-mail because I have some questions
>>>>>>>> regarding the
>>>>>>>> >>> enhancement request that enables configurable session limiting
>>>>>>>> in
>>>>>>>> >>> Keycloak
>>>>>>>> >>> as discussed here:
>>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>>> that Marc
>>>>>>>> >>> Wijma
>>>>>>>> >>> referred to in his comment as being available for this task is
>>>>>>>> me btw :))
>>>>>>>> >>>
>>>>>>>> >>> In the comments a solution is proposed that makes use of a
>>>>>>>> custom
>>>>>>>> >>> Authenticator that is dropped into the authentication flow
>>>>>>>> where it can
>>>>>>>> >>> be
>>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>>> existing
>>>>>>>> >>> components as much as possible (including the configuration
>>>>>>>> options in
>>>>>>>> >>> that
>>>>>>>> >>> flow), I am wondering if this is the best solution. As far as I
>>>>>>>> can tell,
>>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>>> Moreover this
>>>>>>>> >>> functionality operates 'above' the authentication mechanisms
>>>>>>>> and should
>>>>>>>> >>> apply to all of them.
>>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>>> this? Or is
>>>>>>>> >>> this just the quickest route, while not being the most
>>>>>>>> desirable option
>>>>>>>> >>> for
>>>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>>>> would place
>>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>>> >>> configuration
>>>>>>>> >>> code for instance.
>>>>>>>> >>>
>>>>>>>> >>> I just now started investigating this task and looking into the
>>>>>>>> options
>>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>>> >>>
>>>>>>>> >>> Regards
>>>>>>>> >>>
>>>>>>>> >>> Mauro
>>>>>>>> >>>
>>>>>>>> >>> >
>>>>>>>> >>> _______________________________________________
>>>>>>>> >>> keycloak-dev mailing list
>>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> >>>
>>>>>>>> >>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>

From psilva at redhat.com  Wed Mar 20 11:02:22 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Mar 2019 12:02:22 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
Message-ID: <CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>

On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Is it this stuff you're thinking about:
>>>
>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>
>>> From that it does a get including the ticket as a query parameter. I
>>> don't like the idea of sending tickets as query params as they could be
>>> logged. For the application initiated action it would have to be an ID
>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>> creating a ticket that can only be used to initiate an action.
>>>
>>
>> Why you need to send the id token if the client already got an id token
>> and, considering browser flow, there is a cookie that can be used by
>> Keycloak to identify the client/user ?
>>
>
> Cookie doesn't authenticate the client, only the user.
>

But the identity cookie has the user session and from it we can check
whether or not the client initiating the action (client_id) has a
authenticated client session, no ?


>
>
>>
>>
>>>
>>> Perhaps what we could do is:
>>>
>>> 1. By default any application can initiate an action
>>> 1.1. To initiate an action there's no need for a ticket of any sort,
>>> just a regular oauth flow
>>> 2. Later add support if demand to limit what applications can initiate
>>> actions
>>> 2.1 Same as before if the action being initiated is open for everyone
>>> then no need for a ticket
>>> 2.2 If the action being initiated is only permitted by some applications
>>> we would need some form of authentication.
>>>
>>> For 2.2 I have 3 suggestions in mind:
>>>
>>> a. Just include id_token as a ticket query param like  UMA claim
>>> redirect does
>>> b. Add support to obtain an initiate action ticket from a endpoint using
>>> an id token as bearer token
>>> c. Add a note into client session with a initiate action ticket for
>>> clients that can initiate actions and map this into the id token.
>>>
>>
>> Not sure ...
>>
>> If you think about it, the part interested in obtaining the claims after
>> an action is completed is not the client but the audience of the token, the
>> resource server. In this case, the UMA approach seems more appropriate
>> because the resource server is in control about what actions the client
>> should initiate in order to fulfill the constraints imposed by the resource
>> server to access its protected resources. Where these constraints could be
>> a DOB in the token or a higher security level.
>>
>> The app initiating actions in the server is not the goal, but the tool to
>> obtain additional claims from the server ...
>>
>> However, for some applications acting as both client and resource server
>> (e.g.: a monolithic jee) can avoid all the ticket dance and just redirect
>> the user to the server as you pointed out in 1.
>>
>
> Perhaps there's a case for that, but that would be claims gathering, not
> application initiated actions.
>
> Application initiated actions are more a tool for folks to add actions for
> the user account into their own GUIs, and as such should be a simple
> protocol. OAuth incremental scopes for example doesn't have any flows
> between app and service, but rather just allows the app to get the scopes
> it out of bounds knows it needs for specific actions.
>

I think claims gathering and AIA are pretty much the same thing. Both are
querying the user for additional information. Despite if you are initiating
an action to request user's DOB or update a password, they are steps that
the user must perform in order to enrich its security context and be able
to continue using both client and resource server.

The point I'm trying to make is that AIA can solve other problems too. You
would still solve the original problem from your design document as defined
in the motivation section. While you would also help with step-up
authentication and UMA claims gathering. Another point is related to the
party interested in the action. Is it the client or the resource server
(the API)?

If the client (which honestly I don't see much use as most apps seem to be
a combination of front-end + back-end, where the functionality is provided
by the back-end and protected by a bearer token) then you may just consider
passing the "kc_action" parameter and have the action initiated.

If the resource server, you could associate the required actions with the
scopes. So when a client requests a specific scope, Keycloak will start the
action(s) and query the user for some information prior to issuing the
access token.

Still, if the resource server, the resource server could respond to the
client (e.g: UMA flow) indicating that it needs more info, then the client
will just redirect the user to the location provided in the response to
initiate the actions.


>
>
>>
>>
>>>
>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Why do you think authentication/authorization is required? The user
>>>>>>>> will be prompted before making an action and it's an action they do against
>>>>>>>> RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>
>>>>>>>
>>>>>>> The client is making the request and even though the user is at the
>>>>>>> Keycloak server to perform the action, admins may want to restrict which
>>>>>>> clients are allowed to perform such actions. That is what I mean by some
>>>>>>> level of authorization.
>>>>>>>
>>>>>>> You could even consider not authenticating the client at all, but
>>>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>>>> actions on the server.
>>>>>>>
>>>>>>
>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>> actions will work without authenticating the client.
>>>>>>
>>>>>
>>>>> Maybe the word authenticate seems too much to what we are discussing.
>>>>> This is more a validation of the client making the request. Considering
>>>>> that, I'm saying that you could just rely on client_id and redirect uris
>>>>> (the client is already authenticated and if doing browser authentication
>>>>> the cookie is already present) and possibly add some level of authorization
>>>>> to enforce which clients can perform actions (instead of just relying on
>>>>> the authenticated session). Redirect uris are really important because you
>>>>> want to make sure the redirect uri is valid before redirecting the user.
>>>>>
>>>>
>>>> The plan is to use the auth endpoint, so client_id and redirect_uris
>>>> are already being checked. It's just a standard OAuth flow.
>>>>
>>>> IMO that's fine as long as there's no need to limit what clients can
>>>> initiate actions. If that's needed then we need something more complicated
>>>> that properly authenticates the client, as anyone could just use the
>>>> client_id and redirect_uri from a different application to get the action
>>>> initiated (although wouldn't then have the user redirected back to the app
>>>> of course).
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> One way is to follow authorization code constraints like checking
>>>>>>>>> the client_id and redirect_uri (assuming the user will be redirected back
>>>>>>>>> after the action completes). But still, we could also add some level
>>>>>>>>> authorization.
>>>>>>>>>
>>>>>>>>
>>>>>>>> authorization code constraints doesn't work as anyone can just use
>>>>>>>> the client_id and redirect_uri from a different client.
>>>>>>>>
>>>>>>>
>>>>>>> I may be missing the whole flow. I would ask then what happens after
>>>>>>> the user performs an action. Is he/her redirected back to the client ? If
>>>>>>> so, client_id + redirect_uri do work to make sure that the client is known
>>>>>>> and that the user will be redirected back to a valid URI.
>>>>>>>
>>>>>>
>>>>>> It's just a standard OAuth flow, so app would get new tokens. Say the
>>>>>> user hasn't entered a DOB in the profile and the client wants that, then
>>>>>> they can request the user to enter a DOB, which would then result in the
>>>>>> DOB being available in the token.
>>>>>>
>>>>>
>>>>> This flow seems very closely related with the Claims Gathering Flow
>>>>> from UMA specs. We could probably review what is there and see if it can
>>>>> help to solve this problem of app initiated actions.
>>>>>
>>>>
>>>> Go for it ;)
>>>>
>>>>
>>>>>
>>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Only viable option I can think of is to add an endpoint where the
>>>>>>>> application can request a token to initate an action. So flow would be:
>>>>>>>>
>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>>>>> token in header to a new endpoint. This would return a single use token.
>>>>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>
>>>>>>>> In the JS adapter we can add a action(actionId) function that would
>>>>>>>> get the action token before redirecting the user.
>>>>>>>>
>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> The issue is more around how to authenticate clients and also the
>>>>>>>>>> fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>>> the OIDC flows.
>>>>>>>>>>
>>>>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>>>>
>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>>
>>>>>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>>>>>> wanting to
>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>>> securing it and
>>>>>>>>>>>> requiring actions to prompt the user before doing anything, but
>>>>>>>>>>>> welcome
>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>> (always
>>>>>>>>>>>> > prompts user) possible and actions are predefined at keycloak
>>>>>>>>>>>> I see no
>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>> > wrote:
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>>>> prompt the user
>>>>>>>>>>>> > to
>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>>>>> email, etc.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>> registered with the
>>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>>> themselves. As an
>>>>>>>>>>>> > > example it may not be required by all users to verify their
>>>>>>>>>>>> email, but
>>>>>>>>>>>> > only
>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>>>> management
>>>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>>>> verifying the
>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > With that in mind we are proposing to introduce Application
>>>>>>>>>>>> Initiated
>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the scenes
>>>>>>>>>>>> is just a
>>>>>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>>>>>> depending on
>>>>>>>>>>>> > the
>>>>>>>>>>>> > > action may be optional for the user to complete (where the
>>>>>>>>>>>> user can
>>>>>>>>>>>> > select
>>>>>>>>>>>> > > cancel which would return the user back to the application).
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > No Application Initiated Actions should perform any updates
>>>>>>>>>>>> to the users
>>>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>>>> application
>>>>>>>>>>>> > > initiated action that is used to link an existing account
>>>>>>>>>>>> to a social
>>>>>>>>>>>> > > provider should ask the user first if they want to link to
>>>>>>>>>>>> the provider.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > To make it easy for applications to integrate these I would
>>>>>>>>>>>> like to
>>>>>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>>>>>> authenticate
>>>>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>>>>> would redirect
>>>>>>>>>>>> > to
>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>> alias> query
>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>> > > Actions always prompt the user first do we need to add some
>>>>>>>>>>>> mechanism in
>>>>>>>>>>>> > > place to restrict what clients/applications are permitted
>>>>>>>>>>>> to initiate an
>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>> applications.
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>>>> Application
>>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>>> prior to
>>>>>>>>>>>> > performing
>>>>>>>>>>>> > > the action. For example update password should require the
>>>>>>>>>>>> user to enter
>>>>>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>>>>>> simply sends
>>>>>>>>>>>> > an
>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>> >
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>
>>>>>>>>>>>

From sthorger at redhat.com  Wed Mar 20 11:27:51 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Mar 2019 16:27:51 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
Message-ID: <CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>

On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Is it this stuff you're thinking about:
>>>>
>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>
>>>> From that it does a get including the ticket as a query parameter. I
>>>> don't like the idea of sending tickets as query params as they could be
>>>> logged. For the application initiated action it would have to be an ID
>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>> creating a ticket that can only be used to initiate an action.
>>>>
>>>
>>> Why you need to send the id token if the client already got an id token
>>> and, considering browser flow, there is a cookie that can be used by
>>> Keycloak to identify the client/user ?
>>>
>>
>> Cookie doesn't authenticate the client, only the user.
>>
>
> But the identity cookie has the user session and from it we can check
> whether or not the client initiating the action (client_id) has a
> authenticated client session, no ?
>

That only proves that the client_id belongs to a client that has obtained a
token. It doesn't authenticate the client in any way.

Q- Why is authentication of the client required? IMO it is not required.


>
>
>>
>>
>>>
>>>
>>>>
>>>> Perhaps what we could do is:
>>>>
>>>> 1. By default any application can initiate an action
>>>> 1.1. To initiate an action there's no need for a ticket of any sort,
>>>> just a regular oauth flow
>>>> 2. Later add support if demand to limit what applications can initiate
>>>> actions
>>>> 2.1 Same as before if the action being initiated is open for everyone
>>>> then no need for a ticket
>>>> 2.2 If the action being initiated is only permitted by some
>>>> applications we would need some form of authentication.
>>>>
>>>> For 2.2 I have 3 suggestions in mind:
>>>>
>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>> redirect does
>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>> using an id token as bearer token
>>>> c. Add a note into client session with a initiate action ticket for
>>>> clients that can initiate actions and map this into the id token.
>>>>
>>>
>>> Not sure ...
>>>
>>> If you think about it, the part interested in obtaining the claims after
>>> an action is completed is not the client but the audience of the token, the
>>> resource server. In this case, the UMA approach seems more appropriate
>>> because the resource server is in control about what actions the client
>>> should initiate in order to fulfill the constraints imposed by the resource
>>> server to access its protected resources. Where these constraints could be
>>> a DOB in the token or a higher security level.
>>>
>>> The app initiating actions in the server is not the goal, but the tool
>>> to obtain additional claims from the server ...
>>>
>>> However, for some applications acting as both client and resource server
>>> (e.g.: a monolithic jee) can avoid all the ticket dance and just redirect
>>> the user to the server as you pointed out in 1.
>>>
>>
>> Perhaps there's a case for that, but that would be claims gathering, not
>> application initiated actions.
>>
>> Application initiated actions are more a tool for folks to add actions
>> for the user account into their own GUIs, and as such should be a simple
>> protocol. OAuth incremental scopes for example doesn't have any flows
>> between app and service, but rather just allows the app to get the scopes
>> it out of bounds knows it needs for specific actions.
>>
>
> I think claims gathering and AIA are pretty much the same thing. Both are
> querying the user for additional information. Despite if you are initiating
> an action to request user's DOB or update a password, they are steps that
> the user must perform in order to enrich its security context and be able
> to continue using both client and resource server.
>
> The point I'm trying to make is that AIA can solve other problems too. You
> would still solve the original problem from your design document as defined
> in the motivation section. While you would also help with step-up
> authentication and UMA claims gathering. Another point is related to the
> party interested in the action. Is it the client or the resource server
> (the API)?
>

>

> If the client (which honestly I don't see much use as most apps seem to be
> a combination of front-end + back-end, where the functionality is provided
> by the back-end and protected by a bearer token) then you may just consider
> passing the "kc_action" parameter and have the action initiated.
>
> If the resource server, you could associate the required actions with the
> scopes. So when a client requests a specific scope, Keycloak will start the
> action(s) and query the user for some information prior to issuing the
> access token.
>
> Still, if the resource server, the resource server could respond to the
> client (e.g: UMA flow) indicating that it needs more info, then the client
> will just redirect the user to the location provided in the response to
> initiate the actions.
>

I don't understand what your point is or what you are proposing here.


>
>
>>
>>
>>>
>>>
>>>>
>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Why do you think authentication/authorization is required? The
>>>>>>>>> user will be prompted before making an action and it's an action they do
>>>>>>>>> against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The client is making the request and even though the user is at the
>>>>>>>> Keycloak server to perform the action, admins may want to restrict which
>>>>>>>> clients are allowed to perform such actions. That is what I mean by some
>>>>>>>> level of authorization.
>>>>>>>>
>>>>>>>> You could even consider not authenticating the client at all, but
>>>>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>>>>> actions on the server.
>>>>>>>>
>>>>>>>
>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>> actions will work without authenticating the client.
>>>>>>>
>>>>>>
>>>>>> Maybe the word authenticate seems too much to what we are discussing.
>>>>>> This is more a validation of the client making the request. Considering
>>>>>> that, I'm saying that you could just rely on client_id and redirect uris
>>>>>> (the client is already authenticated and if doing browser authentication
>>>>>> the cookie is already present) and possibly add some level of authorization
>>>>>> to enforce which clients can perform actions (instead of just relying on
>>>>>> the authenticated session). Redirect uris are really important because you
>>>>>> want to make sure the redirect uri is valid before redirecting the user.
>>>>>>
>>>>>
>>>>> The plan is to use the auth endpoint, so client_id and redirect_uris
>>>>> are already being checked. It's just a standard OAuth flow.
>>>>>
>>>>> IMO that's fine as long as there's no need to limit what clients can
>>>>> initiate actions. If that's needed then we need something more complicated
>>>>> that properly authenticates the client, as anyone could just use the
>>>>> client_id and redirect_uri from a different application to get the action
>>>>> initiated (although wouldn't then have the user redirected back to the app
>>>>> of course).
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> One way is to follow authorization code constraints like checking
>>>>>>>>>> the client_id and redirect_uri (assuming the user will be redirected back
>>>>>>>>>> after the action completes). But still, we could also add some level
>>>>>>>>>> authorization.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> authorization code constraints doesn't work as anyone can just use
>>>>>>>>> the client_id and redirect_uri from a different client.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>
>>>>>>>
>>>>>>> It's just a standard OAuth flow, so app would get new tokens. Say
>>>>>>> the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>> the DOB being available in the token.
>>>>>>>
>>>>>>
>>>>>> This flow seems very closely related with the Claims Gathering Flow
>>>>>> from UMA specs. We could probably review what is there and see if it can
>>>>>> help to solve this problem of app initiated actions.
>>>>>>
>>>>>
>>>>> Go for it ;)
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Only viable option I can think of is to add an endpoint where the
>>>>>>>>> application can request a token to initate an action. So flow would be:
>>>>>>>>>
>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>>>>>> token in header to a new endpoint. This would return a single use token.
>>>>>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>
>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>
>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> The issue is more around how to authenticate clients and also
>>>>>>>>>>> the fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>>>> the OIDC flows.
>>>>>>>>>>>
>>>>>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Especially around not having any authentication of the clients
>>>>>>>>>>>>> wanting to
>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>>>> securing it and
>>>>>>>>>>>>> requiring actions to prompt the user before doing anything,
>>>>>>>>>>>>> but welcome
>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <pskopek at redhat.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>> (always
>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>>>>> prompt the user
>>>>>>>>>>>>> > to
>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>>>>>> email, etc.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>>>> themselves. As an
>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>> > only
>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>>>>> management
>>>>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>>>>> verifying the
>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the scenes
>>>>>>>>>>>>> is just a
>>>>>>>>>>>>> > > Required Action, but it is initiated by an application and
>>>>>>>>>>>>> depending on
>>>>>>>>>>>>> > the
>>>>>>>>>>>>> > > action may be optional for the user to complete (where the
>>>>>>>>>>>>> user can
>>>>>>>>>>>>> > select
>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>> application).
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>>>>> application
>>>>>>>>>>>>> > > initiated action that is used to link an existing account
>>>>>>>>>>>>> to a social
>>>>>>>>>>>>> > > provider should ask the user first if they want to link to
>>>>>>>>>>>>> the provider.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>> would like to
>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications use to
>>>>>>>>>>>>> authenticate
>>>>>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>>>>>> would redirect
>>>>>>>>>>>>> > to
>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>> > > Actions always prompt the user first do we need to add
>>>>>>>>>>>>> some mechanism in
>>>>>>>>>>>>> > > place to restrict what clients/applications are permitted
>>>>>>>>>>>>> to initiate an
>>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>>> applications.
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>>>>> Application
>>>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>>>> prior to
>>>>>>>>>>>>> > performing
>>>>>>>>>>>>> > > the action. For example update password should require the
>>>>>>>>>>>>> user to enter
>>>>>>>>>>>>> > > the current password, while verify email should not (as it
>>>>>>>>>>>>> simply sends
>>>>>>>>>>>>> > an
>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>> >
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>

From psilva at redhat.com  Wed Mar 20 12:19:05 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Mar 2019 13:19:05 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
Message-ID: <CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>

On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Is it this stuff you're thinking about:
>>>>>
>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>
>>>>> From that it does a get including the ticket as a query parameter. I
>>>>> don't like the idea of sending tickets as query params as they could be
>>>>> logged. For the application initiated action it would have to be an ID
>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>> creating a ticket that can only be used to initiate an action.
>>>>>
>>>>
>>>> Why you need to send the id token if the client already got an id token
>>>> and, considering browser flow, there is a cookie that can be used by
>>>> Keycloak to identify the client/user ?
>>>>
>>>
>>> Cookie doesn't authenticate the client, only the user.
>>>
>>
>> But the identity cookie has the user session and from it we can check
>> whether or not the client initiating the action (client_id) has a
>> authenticated client session, no ?
>>
>
> That only proves that the client_id belongs to a client that has obtained
> a token. It doesn't authenticate the client in any way.
>
> Q- Why is authentication of the client required? IMO it is not required.
>

Sure, but the client obtained token and is authenticated, thus acting on
behalf of the user. If the client is already acting on behalf of a user, we
don't need to authenticate it.


>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Perhaps what we could do is:
>>>>>
>>>>> 1. By default any application can initiate an action
>>>>> 1.1. To initiate an action there's no need for a ticket of any sort,
>>>>> just a regular oauth flow
>>>>> 2. Later add support if demand to limit what applications can initiate
>>>>> actions
>>>>> 2.1 Same as before if the action being initiated is open for everyone
>>>>> then no need for a ticket
>>>>> 2.2 If the action being initiated is only permitted by some
>>>>> applications we would need some form of authentication.
>>>>>
>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>
>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>> redirect does
>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>> using an id token as bearer token
>>>>> c. Add a note into client session with a initiate action ticket for
>>>>> clients that can initiate actions and map this into the id token.
>>>>>
>>>>
>>>> Not sure ...
>>>>
>>>> If you think about it, the part interested in obtaining the claims
>>>> after an action is completed is not the client but the audience of the
>>>> token, the resource server. In this case, the UMA approach seems more
>>>> appropriate because the resource server is in control about what actions
>>>> the client should initiate in order to fulfill the constraints imposed by
>>>> the resource server to access its protected resources. Where these
>>>> constraints could be a DOB in the token or a higher security level.
>>>>
>>>> The app initiating actions in the server is not the goal, but the tool
>>>> to obtain additional claims from the server ...
>>>>
>>>> However, for some applications acting as both client and resource
>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>> redirect the user to the server as you pointed out in 1.
>>>>
>>>
>>> Perhaps there's a case for that, but that would be claims gathering, not
>>> application initiated actions.
>>>
>>> Application initiated actions are more a tool for folks to add actions
>>> for the user account into their own GUIs, and as such should be a simple
>>> protocol. OAuth incremental scopes for example doesn't have any flows
>>> between app and service, but rather just allows the app to get the scopes
>>> it out of bounds knows it needs for specific actions.
>>>
>>
>> I think claims gathering and AIA are pretty much the same thing. Both are
>> querying the user for additional information. Despite if you are initiating
>> an action to request user's DOB or update a password, they are steps that
>> the user must perform in order to enrich its security context and be able
>> to continue using both client and resource server.
>>
>> The point I'm trying to make is that AIA can solve other problems too.
>> You would still solve the original problem from your design document as
>> defined in the motivation section. While you would also help with step-up
>> authentication and UMA claims gathering. Another point is related to the
>> party interested in the action. Is it the client or the resource server
>> (the API)?
>>
>
>>
>
>> If the client (which honestly I don't see much use as most apps seem to
>> be a combination of front-end + back-end, where the functionality is
>> provided by the back-end and protected by a bearer token) then you may just
>> consider passing the "kc_action" parameter and have the action initiated.
>>
>> If the resource server, you could associate the required actions with the
>> scopes. So when a client requests a specific scope, Keycloak will start the
>> action(s) and query the user for some information prior to issuing the
>> access token.
>>
>> Still, if the resource server, the resource server could respond to the
>> client (e.g: UMA flow) indicating that it needs more info, then the client
>> will just redirect the user to the location provided in the response to
>> initiate the actions.
>>
>
> I don't understand what your point is or what you are proposing here.
>

And I do understand your point of view. I just think that it can do much
more than address new account management console requirements.

Based on your design document, I understand what you described in the
Motivation section. But again, instead of considering the "two things" that
originated the idea behind AIA, I think we can take the opportunity and do
much more. As they seem related to me. Especially after your DOB example.


>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Why do you think authentication/authorization is required? The
>>>>>>>>>> user will be prompted before making an action and it's an action they do
>>>>>>>>>> against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The client is making the request and even though the user is at
>>>>>>>>> the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>> some level of authorization.
>>>>>>>>>
>>>>>>>>> You could even consider not authenticating the client at all, but
>>>>>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>>>>>> actions on the server.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>> actions will work without authenticating the client.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>> redirecting the user.
>>>>>>>
>>>>>>
>>>>>> The plan is to use the auth endpoint, so client_id and redirect_uris
>>>>>> are already being checked. It's just a standard OAuth flow.
>>>>>>
>>>>>> IMO that's fine as long as there's no need to limit what clients can
>>>>>> initiate actions. If that's needed then we need something more complicated
>>>>>> that properly authenticates the client, as anyone could just use the
>>>>>> client_id and redirect_uri from a different application to get the action
>>>>>> initiated (although wouldn't then have the user redirected back to the app
>>>>>> of course).
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>> some level authorization.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> authorization code constraints doesn't work as anyone can just
>>>>>>>>>> use the client_id and redirect_uri from a different client.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It's just a standard OAuth flow, so app would get new tokens. Say
>>>>>>>> the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>> the DOB being available in the token.
>>>>>>>>
>>>>>>>
>>>>>>> This flow seems very closely related with the Claims Gathering Flow
>>>>>>> from UMA specs. We could probably review what is there and see if it can
>>>>>>> help to solve this problem of app initiated actions.
>>>>>>>
>>>>>>
>>>>>> Go for it ;)
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Only viable option I can think of is to add an endpoint where the
>>>>>>>>>> application can request a token to initate an action. So flow would be:
>>>>>>>>>>
>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as bearer
>>>>>>>>>> token in header to a new endpoint. This would return a single use token.
>>>>>>>>>> 2. App can now do the redirect protocol as before, but instead of
>>>>>>>>>> "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>
>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>
>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The issue is more around how to authenticate clients and also
>>>>>>>>>>>> the fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>>>>> the OIDC flows.
>>>>>>>>>>>>
>>>>>>>>>>>> So with those constraints how would you authenticate the client?
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>>>>> securing it and
>>>>>>>>>>>>>> requiring actions to prompt the user before doing anything,
>>>>>>>>>>>>>> but welcome
>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>>>>>> prompt the user
>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile, validate
>>>>>>>>>>>>>> email, etc.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>>>>> themselves. As an
>>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>>>>>> management
>>>>>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>>>>>> verifying the
>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>> > > Required Action, but it is initiated by an application
>>>>>>>>>>>>>> and depending on
>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>> > > action may be optional for the user to complete (where
>>>>>>>>>>>>>> the user can
>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> > > initiated action that is used to link an existing account
>>>>>>>>>>>>>> to a social
>>>>>>>>>>>>>> > > provider should ask the user first if they want to link
>>>>>>>>>>>>>> to the provider.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications use
>>>>>>>>>>>>>> to authenticate
>>>>>>>>>>>>>> > > users. So to initiate verify-email action the application
>>>>>>>>>>>>>> would redirect
>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to add
>>>>>>>>>>>>>> some mechanism in
>>>>>>>>>>>>>> > > place to restrict what clients/applications are permitted
>>>>>>>>>>>>>> to initiate an
>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>>>> applications.
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>>>>>> Application
>>>>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>>>>> prior to
>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>> > > the action. For example update password should require
>>>>>>>>>>>>>> the user to enter
>>>>>>>>>>>>>> > > the current password, while verify email should not (as
>>>>>>>>>>>>>> it simply sends
>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>

From sthorger at redhat.com  Wed Mar 20 12:32:54 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Mar 2019 17:32:54 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
Message-ID: <CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>

On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Is it this stuff you're thinking about:
>>>>>>
>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>
>>>>>> From that it does a get including the ticket as a query parameter. I
>>>>>> don't like the idea of sending tickets as query params as they could be
>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>
>>>>>
>>>>> Why you need to send the id token if the client already got an id
>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>> Keycloak to identify the client/user ?
>>>>>
>>>>
>>>> Cookie doesn't authenticate the client, only the user.
>>>>
>>>
>>> But the identity cookie has the user session and from it we can check
>>> whether or not the client initiating the action (client_id) has a
>>> authenticated client session, no ?
>>>
>>
>> That only proves that the client_id belongs to a client that has obtained
>> a token. It doesn't authenticate the client in any way.
>>
>> Q- Why is authentication of the client required? IMO it is not required.
>>
>
> Sure, but the client obtained token and is authenticated, thus acting on
> behalf of the user. If the client is already acting on behalf of a user, we
> don't need to authenticate it.
>

That's not correct. All we know is that a client with the same client_id
has obtained a token. Anyone can use the same client_id to initiate an
action.


>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Perhaps what we could do is:
>>>>>>
>>>>>> 1. By default any application can initiate an action
>>>>>> 1.1. To initiate an action there's no need for a ticket of any sort,
>>>>>> just a regular oauth flow
>>>>>> 2. Later add support if demand to limit what applications can
>>>>>> initiate actions
>>>>>> 2.1 Same as before if the action being initiated is open for everyone
>>>>>> then no need for a ticket
>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>> applications we would need some form of authentication.
>>>>>>
>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>
>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>> redirect does
>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>> using an id token as bearer token
>>>>>> c. Add a note into client session with a initiate action ticket for
>>>>>> clients that can initiate actions and map this into the id token.
>>>>>>
>>>>>
>>>>> Not sure ...
>>>>>
>>>>> If you think about it, the part interested in obtaining the claims
>>>>> after an action is completed is not the client but the audience of the
>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>> appropriate because the resource server is in control about what actions
>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>> the resource server to access its protected resources. Where these
>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>
>>>>> The app initiating actions in the server is not the goal, but the tool
>>>>> to obtain additional claims from the server ...
>>>>>
>>>>> However, for some applications acting as both client and resource
>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>> redirect the user to the server as you pointed out in 1.
>>>>>
>>>>
>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>> not application initiated actions.
>>>>
>>>> Application initiated actions are more a tool for folks to add actions
>>>> for the user account into their own GUIs, and as such should be a simple
>>>> protocol. OAuth incremental scopes for example doesn't have any flows
>>>> between app and service, but rather just allows the app to get the scopes
>>>> it out of bounds knows it needs for specific actions.
>>>>
>>>
>>> I think claims gathering and AIA are pretty much the same thing. Both
>>> are querying the user for additional information. Despite if you are
>>> initiating an action to request user's DOB or update a password, they are
>>> steps that the user must perform in order to enrich its security context
>>> and be able to continue using both client and resource server.
>>>
>>> The point I'm trying to make is that AIA can solve other problems too.
>>> You would still solve the original problem from your design document as
>>> defined in the motivation section. While you would also help with step-up
>>> authentication and UMA claims gathering. Another point is related to the
>>> party interested in the action. Is it the client or the resource server
>>> (the API)?
>>>
>>
>>>
>>
>>> If the client (which honestly I don't see much use as most apps seem to
>>> be a combination of front-end + back-end, where the functionality is
>>> provided by the back-end and protected by a bearer token) then you may just
>>> consider passing the "kc_action" parameter and have the action initiated.
>>>
>>> If the resource server, you could associate the required actions with
>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>> the action(s) and query the user for some information prior to issuing the
>>> access token.
>>>
>>> Still, if the resource server, the resource server could respond to the
>>> client (e.g: UMA flow) indicating that it needs more info, then the client
>>> will just redirect the user to the location provided in the response to
>>> initiate the actions.
>>>
>>
>> I don't understand what your point is or what you are proposing here.
>>
>
> And I do understand your point of view. I just think that it can do much
> more than address new account management console requirements.
>
> Based on your design document, I understand what you described in the
> Motivation section. But again, instead of considering the "two things" that
> originated the idea behind AIA, I think we can take the opportunity and do
> much more. As they seem related to me. Especially after your DOB example.
>

I don't see the additional use-cases you are mentioning as related at all.

* Step-up authentication has already clear parameters in OIDC/OAuth to
request high level of authentication. On the implementation side it's about
invoking additional parts of the authentication flow, not to initiate an
required action that has nothing to do with the authentication flow.

* Claims gathering in UMA is about asking the user for additional claims.
AIA can be used as a poor-mans workaround to lack of claims gathering, but
end of the day it's completely different. AIA will allow an app to invoke
the action update_DOB, while claims gaterhing will allow the application to
request the claim DOB.

I don't see what additional things we need to consider for something that
is in the end very simple and can be implemented in a couple hours
including tests if we don't try to make it more complicated.


>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Why do you think authentication/authorization is required? The
>>>>>>>>>>> user will be prompted before making an action and it's an action they do
>>>>>>>>>>> against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The client is making the request and even though the user is at
>>>>>>>>>> the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>> some level of authorization.
>>>>>>>>>>
>>>>>>>>>> You could even consider not authenticating the client at all, but
>>>>>>>>>> still allow admins to enforce which clients should be allowed to initiate
>>>>>>>>>> actions on the server.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>> redirecting the user.
>>>>>>>>
>>>>>>>
>>>>>>> The plan is to use the auth endpoint, so client_id and redirect_uris
>>>>>>> are already being checked. It's just a standard OAuth flow.
>>>>>>>
>>>>>>> IMO that's fine as long as there's no need to limit what clients can
>>>>>>> initiate actions. If that's needed then we need something more complicated
>>>>>>> that properly authenticates the client, as anyone could just use the
>>>>>>> client_id and redirect_uri from a different application to get the action
>>>>>>> initiated (although wouldn't then have the user redirected back to the app
>>>>>>> of course).
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> authorization code constraints doesn't work as anyone can just
>>>>>>>>>>> use the client_id and redirect_uri from a different client.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens. Say
>>>>>>>>> the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>> the DOB being available in the token.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This flow seems very closely related with the Claims Gathering Flow
>>>>>>>> from UMA specs. We could probably review what is there and see if it can
>>>>>>>> help to solve this problem of app initiated actions.
>>>>>>>>
>>>>>>>
>>>>>>> Go for it ;)
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>
>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>> token.
>>>>>>>>>>> 2. App can now do the redirect protocol as before, but instead
>>>>>>>>>>> of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>
>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>
>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The issue is more around how to authenticate clients and also
>>>>>>>>>>>>> the fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>>>>>> the OIDC flows.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>> client?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>>>>>> securing it and
>>>>>>>>>>>>>>> requiring actions to prompt the user before doing anything,
>>>>>>>>>>>>>>> but welcome
>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are used to
>>>>>>>>>>>>>>> prompt the user
>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>>>>>> themselves. As an
>>>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the account
>>>>>>>>>>>>>>> management
>>>>>>>>>>>>>>> > > console. Examples: updating email address should require
>>>>>>>>>>>>>>> verifying the
>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an application
>>>>>>>>>>>>>>> and depending on
>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>> > > action may be optional for the user to complete (where
>>>>>>>>>>>>>>> the user can
>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>> > > account without prompting the user first. For example an
>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>> > > provider should ask the user first if they want to link
>>>>>>>>>>>>>>> to the provider.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications use
>>>>>>>>>>>>>>> to authenticate
>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to add
>>>>>>>>>>>>>>> some mechanism in
>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>>>>> applications.
>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability for an
>>>>>>>>>>>>>>> Application
>>>>>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>>>>>> prior to
>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>> > > the action. For example update password should require
>>>>>>>>>>>>>>> the user to enter
>>>>>>>>>>>>>>> > > the current password, while verify email should not (as
>>>>>>>>>>>>>>> it simply sends
>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

From psilva at redhat.com  Wed Mar 20 14:36:50 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Mar 2019 15:36:50 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
Message-ID: <CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>

On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is it this stuff you're thinking about:
>>>>>>>
>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>
>>>>>>> From that it does a get including the ticket as a query parameter. I
>>>>>>> don't like the idea of sending tickets as query params as they could be
>>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>
>>>>>>
>>>>>> Why you need to send the id token if the client already got an id
>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>> Keycloak to identify the client/user ?
>>>>>>
>>>>>
>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>
>>>>
>>>> But the identity cookie has the user session and from it we can check
>>>> whether or not the client initiating the action (client_id) has a
>>>> authenticated client session, no ?
>>>>
>>>
>>> That only proves that the client_id belongs to a client that has
>>> obtained a token. It doesn't authenticate the client in any way.
>>>
>>> Q- Why is authentication of the client required? IMO it is not required.
>>>
>>
>> Sure, but the client obtained token and is authenticated, thus acting on
>> behalf of the user. If the client is already acting on behalf of a user, we
>> don't need to authenticate it.
>>
>
> That's not correct. All we know is that a client with the same client_id
> has obtained a token. Anyone can use the same client_id to initiate an
> action.
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Perhaps what we could do is:
>>>>>>>
>>>>>>> 1. By default any application can initiate an action
>>>>>>> 1.1. To initiate an action there's no need for a ticket of any sort,
>>>>>>> just a regular oauth flow
>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>> initiate actions
>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>> everyone then no need for a ticket
>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>> applications we would need some form of authentication.
>>>>>>>
>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>
>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>> redirect does
>>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>>> using an id token as bearer token
>>>>>>> c. Add a note into client session with a initiate action ticket for
>>>>>>> clients that can initiate actions and map this into the id token.
>>>>>>>
>>>>>>
>>>>>> Not sure ...
>>>>>>
>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>> after an action is completed is not the client but the audience of the
>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>> appropriate because the resource server is in control about what actions
>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>> the resource server to access its protected resources. Where these
>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>
>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>> tool to obtain additional claims from the server ...
>>>>>>
>>>>>> However, for some applications acting as both client and resource
>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>
>>>>>
>>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>>> not application initiated actions.
>>>>>
>>>>> Application initiated actions are more a tool for folks to add actions
>>>>> for the user account into their own GUIs, and as such should be a simple
>>>>> protocol. OAuth incremental scopes for example doesn't have any flows
>>>>> between app and service, but rather just allows the app to get the scopes
>>>>> it out of bounds knows it needs for specific actions.
>>>>>
>>>>
>>>> I think claims gathering and AIA are pretty much the same thing. Both
>>>> are querying the user for additional information. Despite if you are
>>>> initiating an action to request user's DOB or update a password, they are
>>>> steps that the user must perform in order to enrich its security context
>>>> and be able to continue using both client and resource server.
>>>>
>>>> The point I'm trying to make is that AIA can solve other problems too.
>>>> You would still solve the original problem from your design document as
>>>> defined in the motivation section. While you would also help with step-up
>>>> authentication and UMA claims gathering. Another point is related to the
>>>> party interested in the action. Is it the client or the resource server
>>>> (the API)?
>>>>
>>>
>>>>
>>>
>>>> If the client (which honestly I don't see much use as most apps seem to
>>>> be a combination of front-end + back-end, where the functionality is
>>>> provided by the back-end and protected by a bearer token) then you may just
>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>
>>>> If the resource server, you could associate the required actions with
>>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>>> the action(s) and query the user for some information prior to issuing the
>>>> access token.
>>>>
>>>> Still, if the resource server, the resource server could respond to the
>>>> client (e.g: UMA flow) indicating that it needs more info, then the client
>>>> will just redirect the user to the location provided in the response to
>>>> initiate the actions.
>>>>
>>>
>>> I don't understand what your point is or what you are proposing here.
>>>
>>
>> And I do understand your point of view. I just think that it can do much
>> more than address new account management console requirements.
>>
>> Based on your design document, I understand what you described in the
>> Motivation section. But again, instead of considering the "two things" that
>> originated the idea behind AIA, I think we can take the opportunity and do
>> much more. As they seem related to me. Especially after your DOB example.
>>
>
> I don't see the additional use-cases you are mentioning as related at all.
>

How it is not related ? The audience of the information gathered during the
AIA does impact where the token with the information will be used. If I
need a DOB to access some page in my front-end, this is one thing. If I
need DOB to access some resource protected by a resource server it is
another thing. Both require tokens with different audiences, the former
will probably be an ID Token where the latter the access token.

In OAuth2 the scopes represent the permissions to access protected
resources. Thus, it does make sense to have required actions that can
challenge a user when requesting scopes. Considering your DOB example, if
my client wants to access resource /api/age/check why you want the client
to request kc_action=dob if the scope "dob" is what he needs to access the
API ? Otherwise, you are making the client aware of things that are really
related to the resource server. It is OK the client ask for scope "age", it
is how OAuth2 authorization model works.

UMA leverages OAuth2 in a way that the permission ticket makes the client
really dumb about what it needs to access protected resources. With UMA,
the client will just receive a ticket and with that ticket it can perform
the necessary actions to make a successful authorization request to the
server.


>
> * Step-up authentication has already clear parameters in OIDC/OAuth to
> request high level of authentication. On the implementation side it's about
> invoking additional parts of the authentication flow, not to initiate an
> required action that has nothing to do with the authentication flow.
>

Can we consider a required action as a prompt for 2nd factor, for instance ?


>
> * Claims gathering in UMA is about asking the user for additional claims.
> AIA can be used as a poor-mans workaround to lack of claims gathering, but
> end of the day it's completely different. AIA will allow an app to invoke
> the action update_DOB, while claims gaterhing will allow the application to
> request the claim DOB.
>

Not sure, if the difference is due to updating a piece of info, both flows
request the user for the info. Is just a matter of updating or not updating
the info.


>
> I don't see what additional things we need to consider for something that
> is in the end very simple and can be implemented in a couple hours
> including tests if we don't try to make it more complicated.
>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Why do you think authentication/authorization is required? The
>>>>>>>>>>>> user will be prompted before making an action and it's an action they do
>>>>>>>>>>>> against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The client is making the request and even though the user is at
>>>>>>>>>>> the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>
>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>> redirecting the user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>
>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>> the app of course).
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> authorization code constraints doesn't work as anyone can just
>>>>>>>>>>>> use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens. Say
>>>>>>>>>> the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Go for it ;)
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>> token.
>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but instead
>>>>>>>>>>>> of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>
>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The issue is more around how to authenticate clients and also
>>>>>>>>>>>>>> the fact that clients wanting to initiate actions may be public clients. We
>>>>>>>>>>>>>> also don't want to invent a new protocol for this, but rather just rely on
>>>>>>>>>>>>>> the OIDC flows.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this one.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about not
>>>>>>>>>>>>>>>> securing it and
>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing anything,
>>>>>>>>>>>>>>>> but welcome
>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are used
>>>>>>>>>>>>>>>> to prompt the user
>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>> > > users account, but can not be initiated by applications
>>>>>>>>>>>>>>>> themselves. As an
>>>>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>> > > console. Examples: updating email address should
>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an application
>>>>>>>>>>>>>>>> and depending on
>>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>>> > > action may be optional for the user to complete (where
>>>>>>>>>>>>>>>> the user can
>>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>> > > account without prompting the user first. For example
>>>>>>>>>>>>>>>> an application
>>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>> > > provider should ask the user first if they want to link
>>>>>>>>>>>>>>>> to the provider.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications use
>>>>>>>>>>>>>>>> to authenticate
>>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to add
>>>>>>>>>>>>>>>> some mechanism in
>>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>>>>>> applications.
>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability for
>>>>>>>>>>>>>>>> an Application
>>>>>>>>>>>>>>>> > > Initiated Action to require the user to re-authenticate
>>>>>>>>>>>>>>>> prior to
>>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>>> > > the action. For example update password should require
>>>>>>>>>>>>>>>> the user to enter
>>>>>>>>>>>>>>>> > > the current password, while verify email should not (as
>>>>>>>>>>>>>>>> it simply sends
>>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>> > > https://lists.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 sven-torben.janus at conciso.de  Thu Mar 21 02:48:57 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Thu, 21 Mar 2019 06:48:57 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
Message-ID: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>

Hey all!

I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.

Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
In addition to that, the whole certificate of the user is also available in another LDAP attribute.

I currently see the following options to implement a solution for this:
1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below)
2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.

For both approaches two different implementations come to my mind:

a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.

We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.

Do you have any advice on which way to go here?

[1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
[2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityToModelMapper.java#L57

Regards
Sven-Torben


From sthorger at redhat.com  Thu Mar 21 03:13:15 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Mar 2019 08:13:15 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
Message-ID: <CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>

Pedro,

I really don't understand what your points are and what you propose we do
here.

The use-case we're addressing is the following:

As a user I would like to initiate an action associated with my account
through a front-end application so that I can make changes to my account,
for example to register a WebAuthn security key with my account.

Further, we want an action to be implemented once and re-usable in
login/registration flows as well as from applications managing user
accounts, incuding our new account console. That means our new account
console needs to be able to invoke an action in the login flow, otherwise
we would have to implement actions as react/rest also.

Now the solution I have proposed is simple. It allows an application to
request an action being invoked after the user has authenticated. Think of
it as a "required action" on-demand. It can be implemented with a few lines
of code and easily tested. It is very easy to use as it just means adding
an extra query param to the login flows, which makes it very easy to use
both for confidential and non-confidential clients.

It is not trying to cover claims gathering use-case from UMA. I see no
connection to this and step-up authentication. These both already have
clearly defined protocols. Neither can be used to address the above
use-case.

So please come with a concrete proposal as I have no clue what your
objections are.

On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com> wrote:

>
>
> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>
>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>
>>>>>>>> From that it does a get including the ticket as a query parameter.
>>>>>>>> I don't like the idea of sending tickets as query params as they could be
>>>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>>
>>>>>>>
>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>> Keycloak to identify the client/user ?
>>>>>>>
>>>>>>
>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>
>>>>>
>>>>> But the identity cookie has the user session and from it we can check
>>>>> whether or not the client initiating the action (client_id) has a
>>>>> authenticated client session, no ?
>>>>>
>>>>
>>>> That only proves that the client_id belongs to a client that has
>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>
>>>> Q- Why is authentication of the client required? IMO it is not required.
>>>>
>>>
>>> Sure, but the client obtained token and is authenticated, thus acting on
>>> behalf of the user. If the client is already acting on behalf of a user, we
>>> don't need to authenticate it.
>>>
>>
>> That's not correct. All we know is that a client with the same client_id
>> has obtained a token. Anyone can use the same client_id to initiate an
>> action.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps what we could do is:
>>>>>>>>
>>>>>>>> 1. By default any application can initiate an action
>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>> sort, just a regular oauth flow
>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>> initiate actions
>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>> everyone then no need for a ticket
>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>> applications we would need some form of authentication.
>>>>>>>>
>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>
>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>> redirect does
>>>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>>>> using an id token as bearer token
>>>>>>>> c. Add a note into client session with a initiate action ticket for
>>>>>>>> clients that can initiate actions and map this into the id token.
>>>>>>>>
>>>>>>>
>>>>>>> Not sure ...
>>>>>>>
>>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>>> after an action is completed is not the client but the audience of the
>>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>> the resource server to access its protected resources. Where these
>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>
>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>
>>>>>>> However, for some applications acting as both client and resource
>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>
>>>>>>
>>>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>>>> not application initiated actions.
>>>>>>
>>>>>> Application initiated actions are more a tool for folks to add
>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>
>>>>>
>>>>> I think claims gathering and AIA are pretty much the same thing. Both
>>>>> are querying the user for additional information. Despite if you are
>>>>> initiating an action to request user's DOB or update a password, they are
>>>>> steps that the user must perform in order to enrich its security context
>>>>> and be able to continue using both client and resource server.
>>>>>
>>>>> The point I'm trying to make is that AIA can solve other problems too.
>>>>> You would still solve the original problem from your design document as
>>>>> defined in the motivation section. While you would also help with step-up
>>>>> authentication and UMA claims gathering. Another point is related to the
>>>>> party interested in the action. Is it the client or the resource server
>>>>> (the API)?
>>>>>
>>>>
>>>>>
>>>>
>>>>> If the client (which honestly I don't see much use as most apps seem
>>>>> to be a combination of front-end + back-end, where the functionality is
>>>>> provided by the back-end and protected by a bearer token) then you may just
>>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>>
>>>>> If the resource server, you could associate the required actions with
>>>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>>>> the action(s) and query the user for some information prior to issuing the
>>>>> access token.
>>>>>
>>>>> Still, if the resource server, the resource server could respond to
>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>> client will just redirect the user to the location provided in the response
>>>>> to initiate the actions.
>>>>>
>>>>
>>>> I don't understand what your point is or what you are proposing here.
>>>>
>>>
>>> And I do understand your point of view. I just think that it can do much
>>> more than address new account management console requirements.
>>>
>>> Based on your design document, I understand what you described in the
>>> Motivation section. But again, instead of considering the "two things" that
>>> originated the idea behind AIA, I think we can take the opportunity and do
>>> much more. As they seem related to me. Especially after your DOB example.
>>>
>>
>> I don't see the additional use-cases you are mentioning as related at all.
>>
>
> How it is not related ? The audience of the information gathered during
> the AIA does impact where the token with the information will be used. If I
> need a DOB to access some page in my front-end, this is one thing. If I
> need DOB to access some resource protected by a resource server it is
> another thing. Both require tokens with different audiences, the former
> will probably be an ID Token where the latter the access token.
>
> In OAuth2 the scopes represent the permissions to access protected
> resources. Thus, it does make sense to have required actions that can
> challenge a user when requesting scopes. Considering your DOB example, if
> my client wants to access resource /api/age/check why you want the client
> to request kc_action=dob if the scope "dob" is what he needs to access the
> API ? Otherwise, you are making the client aware of things that are really
> related to the resource server. It is OK the client ask for scope "age", it
> is how OAuth2 authorization model works.
>
> UMA leverages OAuth2 in a way that the permission ticket makes the client
> really dumb about what it needs to access protected resources. With UMA,
> the client will just receive a ticket and with that ticket it can perform
> the necessary actions to make a successful authorization request to the
> server.
>
>
>>
>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>> request high level of authentication. On the implementation side it's about
>> invoking additional parts of the authentication flow, not to initiate an
>> required action that has nothing to do with the authentication flow.
>>
>
> Can we consider a required action as a prompt for 2nd factor, for instance
> ?
>
>
>>
>> * Claims gathering in UMA is about asking the user for additional claims.
>> AIA can be used as a poor-mans workaround to lack of claims gathering, but
>> end of the day it's completely different. AIA will allow an app to invoke
>> the action update_DOB, while claims gaterhing will allow the application to
>> request the claim DOB.
>>
>
> Not sure, if the difference is due to updating a piece of info, both flows
> request the user for the info. Is just a matter of updating or not updating
> the info.
>
>
>>
>> I don't see what additional things we need to consider for something that
>> is in the end very simple and can be implemented in a couple hours
>> including tests if we don't try to make it more complicated.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Why do you think authentication/authorization is required? The
>>>>>>>>>>>>> user will be prompted before making an action and it's an action they do
>>>>>>>>>>>>> against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The client is making the request and even though the user is at
>>>>>>>>>>>> the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>
>>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>> redirecting the user.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>
>>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>> the app of course).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can just
>>>>>>>>>>>>> use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Go for it ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>> token.
>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but instead
>>>>>>>>>>>>> of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions may be public
>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for this, but rather
>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for clients
>>>>>>>>>>>>>>>> initiating an action. This could be as simple as leveraging authz in order
>>>>>>>>>>>>>>>> to define white/black lists of clients. Similar to what a KC extension does
>>>>>>>>>>>>>>>> in regards to authentication.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are used
>>>>>>>>>>>>>>>>> to prompt the user
>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>> > > users account, but can not be initiated by
>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>> > > console. Examples: updating email address should
>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an application
>>>>>>>>>>>>>>>>> and depending on
>>>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>>>> > > action may be optional for the user to complete (where
>>>>>>>>>>>>>>>>> the user can
>>>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>> > > account without prompting the user first. For example
>>>>>>>>>>>>>>>>> an application
>>>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>> > > provider should ask the user first if they want to
>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to add
>>>>>>>>>>>>>>>>> some mechanism in
>>>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use for
>>>>>>>>>>>>>>>>> applications.
>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability for
>>>>>>>>>>>>>>>>> an Application
>>>>>>>>>>>>>>>>> > > Initiated Action to require the user to
>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>>>> > > the action. For example update password should require
>>>>>>>>>>>>>>>>> the user to enter
>>>>>>>>>>>>>>>>> > > the current password, while verify email should not
>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

From mposolda at redhat.com  Thu Mar 21 05:53:35 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 21 Mar 2019 10:53:35 +0100
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
Message-ID: <885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>

Hi,

The solution (a) looks quite specific to the environment and I don't 
think that it will be useful to have this as a generic feature in 
Keycloak.. Solution (b) looks like bit more generally useful, but still 
not 100% sure about adding it to Keycloak... For the solution (b), are 
you talking about the PEM String representation of the X509 certificate, 
which just excludes the initial and final lines (Those with "BEGIN 
CERTIFICATE" and "END CERTIFICATE" )?

Marek

On 21/03/2019 07:48, Sven-Torben Janus wrote:
> Hey all!
>
> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>
> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>
> I currently see the following options to implement a solution for this:
> 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below)
> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>
> For both approaches two different implementations come to my mind:
>
> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>
> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>
> Do you have any advice on which way to go here?
>
> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityToModelMapper.java#L57
>
> Regards
> Sven-Torben
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Thu Mar 21 08:05:07 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 21 Mar 2019 09:05:07 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
Message-ID: <CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>

In addition to everything you said.

* It is not only about making changes to account, but updating tokens with
information from required actions, which not necessarily need to be
persisted.

* For back-end applications, we could also associate these required actions
with scopes. If we could have a required action as "Re-authenticate" or
"Provide 2nd factor", that would also help with step-up authentication. As
an alternative to OIDC acr related parameters/claims. I don't think it
makes sense to bring to the client concerns that are really tied to the
scopes of a resource server. As I said, clients should ask for scopes and
Keycloak should do whatever is necessary to grant these (via consent, via
additional steps/actions). Consider what you mentioned at the end of your
design document at "Require Re-Authentication". Couldn't we leverage AIA
for step-up and ask the user for a more stronger credential ?

* Claims gathering flow is simple. The Keycloak server would return the
endpoint to where the client should redirect the user. After obtaining
information from the user, Keycloak would issue a ticket (instead of code).
The endpoint returned by Keycloak would contain the action associated with
a resource. The endpoint could be the same as what you are using for AIA.





On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Pedro,
>
> I really don't understand what your points are and what you propose we do
> here.
>
> The use-case we're addressing is the following:
>
> As a user I would like to initiate an action associated with my account
> through a front-end application so that I can make changes to my account,
> for example to register a WebAuthn security key with my account.
>
> Further, we want an action to be implemented once and re-usable in
> login/registration flows as well as from applications managing user
> accounts, incuding our new account console. That means our new account
> console needs to be able to invoke an action in the login flow, otherwise
> we would have to implement actions as react/rest also.
>
> Now the solution I have proposed is simple. It allows an application to
> request an action being invoked after the user has authenticated. Think of
> it as a "required action" on-demand. It can be implemented with a few lines
> of code and easily tested. It is very easy to use as it just means adding
> an extra query param to the login flows, which makes it very easy to use
> both for confidential and non-confidential clients.
>
> It is not trying to cover claims gathering use-case from UMA. I see no
> connection to this and step-up authentication. These both already have
> clearly defined protocols. Neither can be used to address the above
> use-case.
>
> So please come with a concrete proposal as I have no clue what your
> objections are.
>
> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>
>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>
>>>>>>>>> From that it does a get including the ticket as a query parameter.
>>>>>>>>> I don't like the idea of sending tickets as query params as they could be
>>>>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>
>>>>>>>
>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>
>>>>>>
>>>>>> But the identity cookie has the user session and from it we can check
>>>>>> whether or not the client initiating the action (client_id) has a
>>>>>> authenticated client session, no ?
>>>>>>
>>>>>
>>>>> That only proves that the client_id belongs to a client that has
>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>
>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>> required.
>>>>>
>>>>
>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>> on behalf of the user. If the client is already acting on behalf of a user,
>>>> we don't need to authenticate it.
>>>>
>>>
>>> That's not correct. All we know is that a client with the same client_id
>>> has obtained a token. Anyone can use the same client_id to initiate an
>>> action.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>
>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>> initiate actions
>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>> everyone then no need for a ticket
>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>
>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>
>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>> redirect does
>>>>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>>>>> using an id token as bearer token
>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>> for clients that can initiate actions and map this into the id token.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure ...
>>>>>>>>
>>>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>>>> after an action is completed is not the client but the audience of the
>>>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>>> the resource server to access its protected resources. Where these
>>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>>
>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>
>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>
>>>>>>>
>>>>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>>>>> not application initiated actions.
>>>>>>>
>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>
>>>>>>
>>>>>> I think claims gathering and AIA are pretty much the same thing. Both
>>>>>> are querying the user for additional information. Despite if you are
>>>>>> initiating an action to request user's DOB or update a password, they are
>>>>>> steps that the user must perform in order to enrich its security context
>>>>>> and be able to continue using both client and resource server.
>>>>>>
>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>> too. You would still solve the original problem from your design document
>>>>>> as defined in the motivation section. While you would also help with
>>>>>> step-up authentication and UMA claims gathering. Another point is related
>>>>>> to the party interested in the action. Is it the client or the resource
>>>>>> server (the API)?
>>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>> If the client (which honestly I don't see much use as most apps seem
>>>>>> to be a combination of front-end + back-end, where the functionality is
>>>>>> provided by the back-end and protected by a bearer token) then you may just
>>>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>>>
>>>>>> If the resource server, you could associate the required actions with
>>>>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>>>>> the action(s) and query the user for some information prior to issuing the
>>>>>> access token.
>>>>>>
>>>>>> Still, if the resource server, the resource server could respond to
>>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>>> client will just redirect the user to the location provided in the response
>>>>>> to initiate the actions.
>>>>>>
>>>>>
>>>>> I don't understand what your point is or what you are proposing here.
>>>>>
>>>>
>>>> And I do understand your point of view. I just think that it can do
>>>> much more than address new account management console requirements.
>>>>
>>>> Based on your design document, I understand what you described in the
>>>> Motivation section. But again, instead of considering the "two things" that
>>>> originated the idea behind AIA, I think we can take the opportunity and do
>>>> much more. As they seem related to me. Especially after your DOB example.
>>>>
>>>
>>> I don't see the additional use-cases you are mentioning as related at
>>> all.
>>>
>>
>> How it is not related ? The audience of the information gathered during
>> the AIA does impact where the token with the information will be used. If I
>> need a DOB to access some page in my front-end, this is one thing. If I
>> need DOB to access some resource protected by a resource server it is
>> another thing. Both require tokens with different audiences, the former
>> will probably be an ID Token where the latter the access token.
>>
>> In OAuth2 the scopes represent the permissions to access protected
>> resources. Thus, it does make sense to have required actions that can
>> challenge a user when requesting scopes. Considering your DOB example, if
>> my client wants to access resource /api/age/check why you want the client
>> to request kc_action=dob if the scope "dob" is what he needs to access the
>> API ? Otherwise, you are making the client aware of things that are really
>> related to the resource server. It is OK the client ask for scope "age", it
>> is how OAuth2 authorization model works.
>>
>> UMA leverages OAuth2 in a way that the permission ticket makes the client
>> really dumb about what it needs to access protected resources. With UMA,
>> the client will just receive a ticket and with that ticket it can perform
>> the necessary actions to make a successful authorization request to the
>> server.
>>
>>
>>>
>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>> request high level of authentication. On the implementation side it's about
>>> invoking additional parts of the authentication flow, not to initiate an
>>> required action that has nothing to do with the authentication flow.
>>>
>>
>> Can we consider a required action as a prompt for 2nd factor, for
>> instance ?
>>
>>
>>>
>>> * Claims gathering in UMA is about asking the user for additional
>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>> gathering, but end of the day it's completely different. AIA will allow an
>>> app to invoke the action update_DOB, while claims gaterhing will allow the
>>> application to request the claim DOB.
>>>
>>
>> Not sure, if the difference is due to updating a piece of info, both
>> flows request the user for the info. Is just a matter of updating or not
>> updating the info.
>>
>>
>>>
>>> I don't see what additional things we need to consider for something
>>> that is in the end very simple and can be implemented in a couple hours
>>> including tests if we don't try to make it more complicated.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>> The user will be prompted before making an action and it's an action they
>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>>
>>>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>>> the app of course).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Go for it ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>> instead of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions may be public
>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for this, but rather
>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple as leveraging authz
>>>>>>>>>>>>>>>>> in order to define white/black lists of clients. Similar to what a KC
>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> > Since there is no "silent" application initiated action
>>>>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are used
>>>>>>>>>>>>>>>>>> to prompt the user
>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>> > > perform an action associated with their account after
>>>>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>>> > > users account, but can not be initiated by
>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>>> > > example it may not be required by all users to verify
>>>>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>>> > > console. Examples: updating email address should
>>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>> application and depending on
>>>>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>>>>> > > action may be optional for the user to complete
>>>>>>>>>>>>>>>>>> (where the user can
>>>>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>>> > > account without prompting the user first. For example
>>>>>>>>>>>>>>>>>> an application
>>>>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>>> > > provider should ask the user first if they want to
>>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these I
>>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>> > > the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to
>>>>>>>>>>>>>>>>>> add some mechanism in
>>>>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use
>>>>>>>>>>>>>>>>>> for applications.
>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability for
>>>>>>>>>>>>>>>>>> an Application
>>>>>>>>>>>>>>>>>> > > Initiated Action to require the user to
>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>>>>> > > the action. For example update password should
>>>>>>>>>>>>>>>>>> require the user to enter
>>>>>>>>>>>>>>>>>> > > the current password, while verify email should not
>>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>> > > https://lists.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 Mar 21 08:44:36 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 21 Mar 2019 08:44:36 -0400
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
Message-ID: <57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>

Pedro,

My only concern is getting this nailed down so we can move forward with 
the new account console.

It sounds like Stian's proposal is simpler, but covers fewer use cases.? 
Is that correct?

Would it be practical to implement Stian's plan and then implement your 
proposal at a later date?

On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
> In addition to everything you said.
>
> * It is not only about making changes to account, but updating tokens with
> information from required actions, which not necessarily need to be
> persisted.
>
> * For back-end applications, we could also associate these required actions
> with scopes. If we could have a required action as "Re-authenticate" or
> "Provide 2nd factor", that would also help with step-up authentication. As
> an alternative to OIDC acr related parameters/claims. I don't think it
> makes sense to bring to the client concerns that are really tied to the
> scopes of a resource server. As I said, clients should ask for scopes and
> Keycloak should do whatever is necessary to grant these (via consent, via
> additional steps/actions). Consider what you mentioned at the end of your
> design document at "Require Re-Authentication". Couldn't we leverage AIA
> for step-up and ask the user for a more stronger credential ?
>
> * Claims gathering flow is simple. The Keycloak server would return the
> endpoint to where the client should redirect the user. After obtaining
> information from the user, Keycloak would issue a ticket (instead of code).
> The endpoint returned by Keycloak would contain the action associated with
> a resource. The endpoint could be the same as what you are using for AIA.
>
>
>
>
>
> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Pedro,
>>
>> I really don't understand what your points are and what you propose we do
>> here.
>>
>> The use-case we're addressing is the following:
>>
>> As a user I would like to initiate an action associated with my account
>> through a front-end application so that I can make changes to my account,
>> for example to register a WebAuthn security key with my account.
>>
>> Further, we want an action to be implemented once and re-usable in
>> login/registration flows as well as from applications managing user
>> accounts, incuding our new account console. That means our new account
>> console needs to be able to invoke an action in the login flow, otherwise
>> we would have to implement actions as react/rest also.
>>
>> Now the solution I have proposed is simple. It allows an application to
>> request an action being invoked after the user has authenticated. Think of
>> it as a "required action" on-demand. It can be implemented with a few lines
>> of code and easily tested. It is very easy to use as it just means adding
>> an extra query param to the login flows, which makes it very easy to use
>> both for confidential and non-confidential clients.
>>
>> It is not trying to cover claims gathering use-case from UMA. I see no
>> connection to this and step-up authentication. These both already have
>> clearly defined protocols. Neither can be used to address the above
>> use-case.
>>
>> So please come with a concrete proposal as I have no clue what your
>> objections are.
>>
>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>>
>>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>>
>>>>>>>>>>  From that it does a get including the ticket as a query parameter.
>>>>>>>>>> I don't like the idea of sending tickets as query params as they could be
>>>>>>>>>> logged. For the application initiated action it would have to be an ID
>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we have a way of
>>>>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>>>>
>>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>>
>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>>
>>>>>>> But the identity cookie has the user session and from it we can check
>>>>>>> whether or not the client initiating the action (client_id) has a
>>>>>>> authenticated client session, no ?
>>>>>>>
>>>>>> That only proves that the client_id belongs to a client that has
>>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>>
>>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>>> required.
>>>>>>
>>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>>> on behalf of the user. If the client is already acting on behalf of a user,
>>>>> we don't need to authenticate it.
>>>>>
>>>> That's not correct. All we know is that a client with the same client_id
>>>> has obtained a token. Anyone can use the same client_id to initiate an
>>>> action.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>>
>>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>>> initiate actions
>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>>> everyone then no need for a ticket
>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>>
>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>>
>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>>> redirect does
>>>>>>>>>> b. Add support to obtain an initiate action ticket from a endpoint
>>>>>>>>>> using an id token as bearer token
>>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>>> for clients that can initiate actions and map this into the id token.
>>>>>>>>>>
>>>>>>>>> Not sure ...
>>>>>>>>>
>>>>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>>>>> after an action is completed is not the client but the audience of the
>>>>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>>>> the resource server to access its protected resources. Where these
>>>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>>>
>>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>>
>>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>>
>>>>>>>> Perhaps there's a case for that, but that would be claims gathering,
>>>>>>>> not application initiated actions.
>>>>>>>>
>>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>>
>>>>>>> I think claims gathering and AIA are pretty much the same thing. Both
>>>>>>> are querying the user for additional information. Despite if you are
>>>>>>> initiating an action to request user's DOB or update a password, they are
>>>>>>> steps that the user must perform in order to enrich its security context
>>>>>>> and be able to continue using both client and resource server.
>>>>>>>
>>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>>> too. You would still solve the original problem from your design document
>>>>>>> as defined in the motivation section. While you would also help with
>>>>>>> step-up authentication and UMA claims gathering. Another point is related
>>>>>>> to the party interested in the action. Is it the client or the resource
>>>>>>> server (the API)?
>>>>>>>
>>>>>>> If the client (which honestly I don't see much use as most apps seem
>>>>>>> to be a combination of front-end + back-end, where the functionality is
>>>>>>> provided by the back-end and protected by a bearer token) then you may just
>>>>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>>>>
>>>>>>> If the resource server, you could associate the required actions with
>>>>>>> the scopes. So when a client requests a specific scope, Keycloak will start
>>>>>>> the action(s) and query the user for some information prior to issuing the
>>>>>>> access token.
>>>>>>>
>>>>>>> Still, if the resource server, the resource server could respond to
>>>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>>>> client will just redirect the user to the location provided in the response
>>>>>>> to initiate the actions.
>>>>>>>
>>>>>> I don't understand what your point is or what you are proposing here.
>>>>>>
>>>>> And I do understand your point of view. I just think that it can do
>>>>> much more than address new account management console requirements.
>>>>>
>>>>> Based on your design document, I understand what you described in the
>>>>> Motivation section. But again, instead of considering the "two things" that
>>>>> originated the idea behind AIA, I think we can take the opportunity and do
>>>>> much more. As they seem related to me. Especially after your DOB example.
>>>>>
>>>> I don't see the additional use-cases you are mentioning as related at
>>>> all.
>>>>
>>> How it is not related ? The audience of the information gathered during
>>> the AIA does impact where the token with the information will be used. If I
>>> need a DOB to access some page in my front-end, this is one thing. If I
>>> need DOB to access some resource protected by a resource server it is
>>> another thing. Both require tokens with different audiences, the former
>>> will probably be an ID Token where the latter the access token.
>>>
>>> In OAuth2 the scopes represent the permissions to access protected
>>> resources. Thus, it does make sense to have required actions that can
>>> challenge a user when requesting scopes. Considering your DOB example, if
>>> my client wants to access resource /api/age/check why you want the client
>>> to request kc_action=dob if the scope "dob" is what he needs to access the
>>> API ? Otherwise, you are making the client aware of things that are really
>>> related to the resource server. It is OK the client ask for scope "age", it
>>> is how OAuth2 authorization model works.
>>>
>>> UMA leverages OAuth2 in a way that the permission ticket makes the client
>>> really dumb about what it needs to access protected resources. With UMA,
>>> the client will just receive a ticket and with that ticket it can perform
>>> the necessary actions to make a successful authorization request to the
>>> server.
>>>
>>>
>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>>> request high level of authentication. On the implementation side it's about
>>>> invoking additional parts of the authentication flow, not to initiate an
>>>> required action that has nothing to do with the authentication flow.
>>>>
>>> Can we consider a required action as a prompt for 2nd factor, for
>>> instance ?
>>>
>>>
>>>> * Claims gathering in UMA is about asking the user for additional
>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>>> gathering, but end of the day it's completely different. AIA will allow an
>>>> app to invoke the action update_DOB, while claims gaterhing will allow the
>>>> application to request the claim DOB.
>>>>
>>> Not sure, if the difference is due to updating a piece of info, both
>>> flows request the user for the info. Is just a matter of updating or not
>>> updating the info.
>>>
>>>
>>>> I don't see what additional things we need to consider for something
>>>> that is in the end very simple and can be implemented in a couple hours
>>>> including tests if we don't try to make it more complicated.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>>> The user will be prompted before making an action and it's an action they
>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>>>
>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>>
>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>>>
>>>>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>>>> the app of course).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what happens
>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected back to the client
>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that the client is
>>>>>>>>>>>>>> known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>>
>>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>>
>>>>>>>>>>> Go for it ;)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint where
>>>>>>>>>>>>>>> the application can request a token to initate an action. So flow would be:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>>> instead of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function that
>>>>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions may be public
>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for this, but rather
>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple as leveraging authz
>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients. Similar to what a KC
>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated action
>>>>>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>>>>> need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are used
>>>>>>>>>>>>>>>>>>> to prompt the user
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account after
>>>>>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to verify
>>>>>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>>>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>>> application and depending on
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>>>>>>>>>>>>>>>>>>> (where the user can
>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>>>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For example
>>>>>>>>>>>>>>>>>>> an application
>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
>>>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
>>>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate these I
>>>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
>>>>>>>>>>>>>>>>>>> for applications.
>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability for
>>>>>>>>>>>>>>>>>>> an Application
>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>>>>> performing
>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>>>>>>>>>>>>>>>>>>> require the user to enter
>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should not
>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>>>> https://lists.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 sthorger at redhat.com  Thu Mar 21 09:05:11 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Mar 2019 14:05:11 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
Message-ID: <CAJgngAfTD4VxJ9EmO1SniJ=csYJCKR4=S__+JGtZvE34UOhMPQ@mail.gmail.com>

I'm still not seeing a concrete proposal from you and as I see it trying to
have AIA solve step-up and claims gathering is a complete broken idea and
will just result in it being overly complex to implement and use.

On Thu, 21 Mar 2019 at 13:05, Pedro Igor Silva <psilva at redhat.com> wrote:

> In addition to everything you said.
>
> * It is not only about making changes to account, but updating tokens with
> information from required actions, which not necessarily need to be
> persisted.
>

Not needed for the use-case I mentioned. Besides if the action makes
additional information available about the user that can be mapped into the
token with mappers and would be available in the updated tokens the app
receives after the action has been completed.


>
> * For back-end applications, we could also associate these required
> actions with scopes. If we could have a required action as
> "Re-authenticate" or "Provide 2nd factor", that would also help with
> step-up authentication. As an alternative to OIDC acr related
> parameters/claims. I don't think it makes sense to bring to the client
> concerns that are really tied to the scopes of a resource server. As I
> said, clients should ask for scopes and Keycloak should do whatever is
> necessary to grant these (via consent, via additional steps/actions).
> Consider what you mentioned at the end of your design document at "Require
> Re-Authentication". Couldn't we leverage AIA for step-up and ask the user
> for a more stronger credential ?
>

Using this for step-up is just completely broken idea. Step-up
authentication is simple. Application requests level=0 initially, Keycloak
authenticates user to level=1, later application requests level=1, Keycloak
authenticates to level=1. The application should not have to ask for a
specific action to be done to step the authentication up. It's up to
Keycloak and how the user is configured to take it to the level the app
wants.

AIA != Step-up authentication



>
> * Claims gathering flow is simple. The Keycloak server would return the
> endpoint to where the client should redirect the user. After obtaining
> information from the user, Keycloak would issue a ticket (instead of code).
> The endpoint returned by Keycloak would contain the action associated with
> a resource. The endpoint could be the same as what you are using for AIA.
>

Endpoint I'm using for AIA is the auth endpoint. It's not a new endpoint,
just one query parameter added. It's asking for a specific action to be
performed (register OTP), not asking for additional claims (I need DOB).
>From briefly reading UMA claims gathering flow it's a completely new
endpoint and has a completely different flow.

AIA != claims gathering


>
>
>
>
>
> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Pedro,
>>
>> I really don't understand what your points are and what you propose we do
>> here.
>>
>> The use-case we're addressing is the following:
>>
>> As a user I would like to initiate an action associated with my account
>> through a front-end application so that I can make changes to my account,
>> for example to register a WebAuthn security key with my account.
>>
>> Further, we want an action to be implemented once and re-usable in
>> login/registration flows as well as from applications managing user
>> accounts, incuding our new account console. That means our new account
>> console needs to be able to invoke an action in the login flow, otherwise
>> we would have to implement actions as react/rest also.
>>
>> Now the solution I have proposed is simple. It allows an application to
>> request an action being invoked after the user has authenticated. Think of
>> it as a "required action" on-demand. It can be implemented with a few lines
>> of code and easily tested. It is very easy to use as it just means adding
>> an extra query param to the login flows, which makes it very easy to use
>> both for confidential and non-confidential clients.
>>
>> It is not trying to cover claims gathering use-case from UMA. I see no
>> connection to this and step-up authentication. These both already have
>> clearly defined protocols. Neither can be used to address the above
>> use-case.
>>
>> So please come with a concrete proposal as I have no clue what your
>> objections are.
>>
>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>>
>>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>>
>>>>>>>>>> From that it does a get including the ticket as a query
>>>>>>>>>> parameter. I don't like the idea of sending tickets as query params as they
>>>>>>>>>> could be logged. For the application initiated action it would have to be
>>>>>>>>>> an ID token sent as the ticket. Or as I mentioned before perhaps we have a
>>>>>>>>>> way of creating a ticket that can only be used to initiate an action.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>>
>>>>>>>
>>>>>>> But the identity cookie has the user session and from it we can
>>>>>>> check whether or not the client initiating the action (client_id) has a
>>>>>>> authenticated client session, no ?
>>>>>>>
>>>>>>
>>>>>> That only proves that the client_id belongs to a client that has
>>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>>
>>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>>> required.
>>>>>>
>>>>>
>>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>>> on behalf of the user. If the client is already acting on behalf of a user,
>>>>> we don't need to authenticate it.
>>>>>
>>>>
>>>> That's not correct. All we know is that a client with the same
>>>> client_id has obtained a token. Anyone can use the same client_id to
>>>> initiate an action.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>>
>>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>>> initiate actions
>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>>> everyone then no need for a ticket
>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>>
>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>>
>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>>> redirect does
>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>>>>>>>>>> endpoint using an id token as bearer token
>>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>>> for clients that can initiate actions and map this into the id token.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure ...
>>>>>>>>>
>>>>>>>>> If you think about it, the part interested in obtaining the claims
>>>>>>>>> after an action is completed is not the client but the audience of the
>>>>>>>>> token, the resource server. In this case, the UMA approach seems more
>>>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>>>> the resource server to access its protected resources. Where these
>>>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>>>
>>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>>
>>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps there's a case for that, but that would be claims
>>>>>>>> gathering, not application initiated actions.
>>>>>>>>
>>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>>
>>>>>>>
>>>>>>> I think claims gathering and AIA are pretty much the same thing.
>>>>>>> Both are querying the user for additional information. Despite if you are
>>>>>>> initiating an action to request user's DOB or update a password, they are
>>>>>>> steps that the user must perform in order to enrich its security context
>>>>>>> and be able to continue using both client and resource server.
>>>>>>>
>>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>>> too. You would still solve the original problem from your design document
>>>>>>> as defined in the motivation section. While you would also help with
>>>>>>> step-up authentication and UMA claims gathering. Another point is related
>>>>>>> to the party interested in the action. Is it the client or the resource
>>>>>>> server (the API)?
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> If the client (which honestly I don't see much use as most apps seem
>>>>>>> to be a combination of front-end + back-end, where the functionality is
>>>>>>> provided by the back-end and protected by a bearer token) then you may just
>>>>>>> consider passing the "kc_action" parameter and have the action initiated.
>>>>>>>
>>>>>>> If the resource server, you could associate the required actions
>>>>>>> with the scopes. So when a client requests a specific scope, Keycloak will
>>>>>>> start the action(s) and query the user for some information prior to
>>>>>>> issuing the access token.
>>>>>>>
>>>>>>> Still, if the resource server, the resource server could respond to
>>>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>>>> client will just redirect the user to the location provided in the response
>>>>>>> to initiate the actions.
>>>>>>>
>>>>>>
>>>>>> I don't understand what your point is or what you are proposing here.
>>>>>>
>>>>>
>>>>> And I do understand your point of view. I just think that it can do
>>>>> much more than address new account management console requirements.
>>>>>
>>>>> Based on your design document, I understand what you described in the
>>>>> Motivation section. But again, instead of considering the "two things" that
>>>>> originated the idea behind AIA, I think we can take the opportunity and do
>>>>> much more. As they seem related to me. Especially after your DOB example.
>>>>>
>>>>
>>>> I don't see the additional use-cases you are mentioning as related at
>>>> all.
>>>>
>>>
>>> How it is not related ? The audience of the information gathered during
>>> the AIA does impact where the token with the information will be used. If I
>>> need a DOB to access some page in my front-end, this is one thing. If I
>>> need DOB to access some resource protected by a resource server it is
>>> another thing. Both require tokens with different audiences, the former
>>> will probably be an ID Token where the latter the access token.
>>>
>>> In OAuth2 the scopes represent the permissions to access protected
>>> resources. Thus, it does make sense to have required actions that can
>>> challenge a user when requesting scopes. Considering your DOB example, if
>>> my client wants to access resource /api/age/check why you want the client
>>> to request kc_action=dob if the scope "dob" is what he needs to access the
>>> API ? Otherwise, you are making the client aware of things that are really
>>> related to the resource server. It is OK the client ask for scope "age", it
>>> is how OAuth2 authorization model works.
>>>
>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>>> client really dumb about what it needs to access protected resources. With
>>> UMA, the client will just receive a ticket and with that ticket it can
>>> perform the necessary actions to make a successful authorization request to
>>> the server.
>>>
>>>
>>>>
>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>>> request high level of authentication. On the implementation side it's about
>>>> invoking additional parts of the authentication flow, not to initiate an
>>>> required action that has nothing to do with the authentication flow.
>>>>
>>>
>>> Can we consider a required action as a prompt for 2nd factor, for
>>> instance ?
>>>
>>>
>>>>
>>>> * Claims gathering in UMA is about asking the user for additional
>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>>> gathering, but end of the day it's completely different. AIA will allow an
>>>> app to invoke the action update_DOB, while claims gaterhing will allow the
>>>> application to request the claim DOB.
>>>>
>>>
>>> Not sure, if the difference is due to updating a piece of info, both
>>> flows request the user for the info. Is just a matter of updating or not
>>> updating the info.
>>>
>>>
>>>>
>>>> I don't see what additional things we need to consider for something
>>>> that is in the end very simple and can be implemented in a couple hours
>>>> including tests if we don't try to make it more complicated.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>>> The user will be prompted before making an action and it's an action they
>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You could even consider not authenticating the client at all,
>>>>>>>>>>>>>> but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to initiate
>>>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>>>
>>>>>>>>>>> IMO that's fine as long as there's no need to limit what clients
>>>>>>>>>>> can initiate actions. If that's needed then we need something more
>>>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>>>> the app of course).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>>>>>>>>>>>>>> happens after the user performs an action. Is he/her redirected back to the
>>>>>>>>>>>>>> client ? If so, client_id + redirect_uri do work to make sure that the
>>>>>>>>>>>>>> client is known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Go for it ;)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>>>>>>>>>>>>>>> where the application can request a token to initate an action. So flow
>>>>>>>>>>>>>>> would be:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>>> instead of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
>>>>>>>>>>>>>>> that would get the action token before redirecting the user.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions may be public
>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for this, but rather
>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple as leveraging authz
>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients. Similar to what a KC
>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> > Since there is no "silent" application initiated
>>>>>>>>>>>>>>>>>>> action (always
>>>>>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are
>>>>>>>>>>>>>>>>>>> used to prompt the user
>>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>>> > > perform an action associated with their account
>>>>>>>>>>>>>>>>>>> after authenticating, but
>>>>>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>>>> > > users account, but can not be initiated by
>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>>>> > > example it may not be required by all users to
>>>>>>>>>>>>>>>>>>> verify their email, but
>>>>>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>>>> > > console. Examples: updating email address should
>>>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>>> application and depending on
>>>>>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>>>>>> > > action may be optional for the user to complete
>>>>>>>>>>>>>>>>>>> (where the user can
>>>>>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>>>> > > account without prompting the user first. For
>>>>>>>>>>>>>>>>>>> example an application
>>>>>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>>>> > > provider should ask the user first if they want to
>>>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these
>>>>>>>>>>>>>>>>>>> I would like to
>>>>>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>>> > > the authentication endpoint and add
>>>>>>>>>>>>>>>>>>> kc_action=<action alias> query
>>>>>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to
>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>>>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use
>>>>>>>>>>>>>>>>>>> for applications.
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability
>>>>>>>>>>>>>>>>>>> for an Application
>>>>>>>>>>>>>>>>>>> > > Initiated Action to require the user to
>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>>>>>> > > the action. For example update password should
>>>>>>>>>>>>>>>>>>> require the user to enter
>>>>>>>>>>>>>>>>>>> > > the current password, while verify email should not
>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>

From psilva at redhat.com  Thu Mar 21 09:07:07 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 21 Mar 2019 10:07:07 -0300
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
Message-ID: <CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>

Sure, I'm not against the initial design/scope. Just tried to make comments
about other aspects that, to me, are related or how it can be leveraged to
also achieve other things.

So, what Stian plans mentioned in one of his replies is fine for me.

On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com> wrote:

> Pedro,
>
> My only concern is getting this nailed down so we can move forward with
> the new account console.
>
> It sounds like Stian's proposal is simpler, but covers fewer use cases.
> Is that correct?
>
> Would it be practical to implement Stian's plan and then implement your
> proposal at a later date?
>
> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
> > In addition to everything you said.
> >
> > * It is not only about making changes to account, but updating tokens
> with
> > information from required actions, which not necessarily need to be
> > persisted.
> >
> > * For back-end applications, we could also associate these required
> actions
> > with scopes. If we could have a required action as "Re-authenticate" or
> > "Provide 2nd factor", that would also help with step-up authentication.
> As
> > an alternative to OIDC acr related parameters/claims. I don't think it
> > makes sense to bring to the client concerns that are really tied to the
> > scopes of a resource server. As I said, clients should ask for scopes and
> > Keycloak should do whatever is necessary to grant these (via consent, via
> > additional steps/actions). Consider what you mentioned at the end of your
> > design document at "Require Re-Authentication". Couldn't we leverage AIA
> > for step-up and ask the user for a more stronger credential ?
> >
> > * Claims gathering flow is simple. The Keycloak server would return the
> > endpoint to where the client should redirect the user. After obtaining
> > information from the user, Keycloak would issue a ticket (instead of
> code).
> > The endpoint returned by Keycloak would contain the action associated
> with
> > a resource. The endpoint could be the same as what you are using for AIA.
> >
> >
> >
> >
> >
> > On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> Pedro,
> >>
> >> I really don't understand what your points are and what you propose we
> do
> >> here.
> >>
> >> The use-case we're addressing is the following:
> >>
> >> As a user I would like to initiate an action associated with my account
> >> through a front-end application so that I can make changes to my
> account,
> >> for example to register a WebAuthn security key with my account.
> >>
> >> Further, we want an action to be implemented once and re-usable in
> >> login/registration flows as well as from applications managing user
> >> accounts, incuding our new account console. That means our new account
> >> console needs to be able to invoke an action in the login flow,
> otherwise
> >> we would have to implement actions as react/rest also.
> >>
> >> Now the solution I have proposed is simple. It allows an application to
> >> request an action being invoked after the user has authenticated. Think
> of
> >> it as a "required action" on-demand. It can be implemented with a few
> lines
> >> of code and easily tested. It is very easy to use as it just means
> adding
> >> an extra query param to the login flows, which makes it very easy to use
> >> both for confidential and non-confidential clients.
> >>
> >> It is not trying to cover claims gathering use-case from UMA. I see no
> >> connection to this and step-up authentication. These both already have
> >> clearly defined protocols. Neither can be used to address the above
> >> use-case.
> >>
> >> So please come with a concrete proposal as I have no clue what your
> >> objections are.
> >>
> >> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >>
> >>>
> >>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
> >>> wrote:
> >>>
> >>>>
> >>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
> sthorger at redhat.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
> sthorger at redhat.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
> >>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Is it this stuff you're thinking about:
> >>>>>>>>>>
> >>>>>>>>>>
> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
> >>>>>>>>>>
> >>>>>>>>>>  From that it does a get including the ticket as a query
> parameter.
> >>>>>>>>>> I don't like the idea of sending tickets as query params as
> they could be
> >>>>>>>>>> logged. For the application initiated action it would have to
> be an ID
> >>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we
> have a way of
> >>>>>>>>>> creating a ticket that can only be used to initiate an action.
> >>>>>>>>>>
> >>>>>>>>> Why you need to send the id token if the client already got an id
> >>>>>>>>> token and, considering browser flow, there is a cookie that can
> be used by
> >>>>>>>>> Keycloak to identify the client/user ?
> >>>>>>>>>
> >>>>>>>> Cookie doesn't authenticate the client, only the user.
> >>>>>>>>
> >>>>>>> But the identity cookie has the user session and from it we can
> check
> >>>>>>> whether or not the client initiating the action (client_id) has a
> >>>>>>> authenticated client session, no ?
> >>>>>>>
> >>>>>> That only proves that the client_id belongs to a client that has
> >>>>>> obtained a token. It doesn't authenticate the client in any way.
> >>>>>>
> >>>>>> Q- Why is authentication of the client required? IMO it is not
> >>>>>> required.
> >>>>>>
> >>>>> Sure, but the client obtained token and is authenticated, thus acting
> >>>>> on behalf of the user. If the client is already acting on behalf of
> a user,
> >>>>> we don't need to authenticate it.
> >>>>>
> >>>> That's not correct. All we know is that a client with the same
> client_id
> >>>> has obtained a token. Anyone can use the same client_id to initiate an
> >>>> action.
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Perhaps what we could do is:
> >>>>>>>>>>
> >>>>>>>>>> 1. By default any application can initiate an action
> >>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
> >>>>>>>>>> sort, just a regular oauth flow
> >>>>>>>>>> 2. Later add support if demand to limit what applications can
> >>>>>>>>>> initiate actions
> >>>>>>>>>> 2.1 Same as before if the action being initiated is open for
> >>>>>>>>>> everyone then no need for a ticket
> >>>>>>>>>> 2.2 If the action being initiated is only permitted by some
> >>>>>>>>>> applications we would need some form of authentication.
> >>>>>>>>>>
> >>>>>>>>>> For 2.2 I have 3 suggestions in mind:
> >>>>>>>>>>
> >>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
> >>>>>>>>>> redirect does
> >>>>>>>>>> b. Add support to obtain an initiate action ticket from a
> endpoint
> >>>>>>>>>> using an id token as bearer token
> >>>>>>>>>> c. Add a note into client session with a initiate action ticket
> >>>>>>>>>> for clients that can initiate actions and map this into the id
> token.
> >>>>>>>>>>
> >>>>>>>>> Not sure ...
> >>>>>>>>>
> >>>>>>>>> If you think about it, the part interested in obtaining the
> claims
> >>>>>>>>> after an action is completed is not the client but the audience
> of the
> >>>>>>>>> token, the resource server. In this case, the UMA approach seems
> more
> >>>>>>>>> appropriate because the resource server is in control about what
> actions
> >>>>>>>>> the client should initiate in order to fulfill the constraints
> imposed by
> >>>>>>>>> the resource server to access its protected resources. Where
> these
> >>>>>>>>> constraints could be a DOB in the token or a higher security
> level.
> >>>>>>>>>
> >>>>>>>>> The app initiating actions in the server is not the goal, but the
> >>>>>>>>> tool to obtain additional claims from the server ...
> >>>>>>>>>
> >>>>>>>>> However, for some applications acting as both client and resource
> >>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance
> and just
> >>>>>>>>> redirect the user to the server as you pointed out in 1.
> >>>>>>>>>
> >>>>>>>> Perhaps there's a case for that, but that would be claims
> gathering,
> >>>>>>>> not application initiated actions.
> >>>>>>>>
> >>>>>>>> Application initiated actions are more a tool for folks to add
> >>>>>>>> actions for the user account into their own GUIs, and as such
> should be a
> >>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
> have any
> >>>>>>>> flows between app and service, but rather just allows the app to
> get the
> >>>>>>>> scopes it out of bounds knows it needs for specific actions.
> >>>>>>>>
> >>>>>>> I think claims gathering and AIA are pretty much the same thing.
> Both
> >>>>>>> are querying the user for additional information. Despite if you
> are
> >>>>>>> initiating an action to request user's DOB or update a password,
> they are
> >>>>>>> steps that the user must perform in order to enrich its security
> context
> >>>>>>> and be able to continue using both client and resource server.
> >>>>>>>
> >>>>>>> The point I'm trying to make is that AIA can solve other problems
> >>>>>>> too. You would still solve the original problem from your design
> document
> >>>>>>> as defined in the motivation section. While you would also help
> with
> >>>>>>> step-up authentication and UMA claims gathering. Another point is
> related
> >>>>>>> to the party interested in the action. Is it the client or the
> resource
> >>>>>>> server (the API)?
> >>>>>>>
> >>>>>>> If the client (which honestly I don't see much use as most apps
> seem
> >>>>>>> to be a combination of front-end + back-end, where the
> functionality is
> >>>>>>> provided by the back-end and protected by a bearer token) then you
> may just
> >>>>>>> consider passing the "kc_action" parameter and have the action
> initiated.
> >>>>>>>
> >>>>>>> If the resource server, you could associate the required actions
> with
> >>>>>>> the scopes. So when a client requests a specific scope, Keycloak
> will start
> >>>>>>> the action(s) and query the user for some information prior to
> issuing the
> >>>>>>> access token.
> >>>>>>>
> >>>>>>> Still, if the resource server, the resource server could respond to
> >>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
> then the
> >>>>>>> client will just redirect the user to the location provided in the
> response
> >>>>>>> to initiate the actions.
> >>>>>>>
> >>>>>> I don't understand what your point is or what you are proposing
> here.
> >>>>>>
> >>>>> And I do understand your point of view. I just think that it can do
> >>>>> much more than address new account management console requirements.
> >>>>>
> >>>>> Based on your design document, I understand what you described in the
> >>>>> Motivation section. But again, instead of considering the "two
> things" that
> >>>>> originated the idea behind AIA, I think we can take the opportunity
> and do
> >>>>> much more. As they seem related to me. Especially after your DOB
> example.
> >>>>>
> >>>> I don't see the additional use-cases you are mentioning as related at
> >>>> all.
> >>>>
> >>> How it is not related ? The audience of the information gathered during
> >>> the AIA does impact where the token with the information will be used.
> If I
> >>> need a DOB to access some page in my front-end, this is one thing. If I
> >>> need DOB to access some resource protected by a resource server it is
> >>> another thing. Both require tokens with different audiences, the former
> >>> will probably be an ID Token where the latter the access token.
> >>>
> >>> In OAuth2 the scopes represent the permissions to access protected
> >>> resources. Thus, it does make sense to have required actions that can
> >>> challenge a user when requesting scopes. Considering your DOB example,
> if
> >>> my client wants to access resource /api/age/check why you want the
> client
> >>> to request kc_action=dob if the scope "dob" is what he needs to access
> the
> >>> API ? Otherwise, you are making the client aware of things that are
> really
> >>> related to the resource server. It is OK the client ask for scope
> "age", it
> >>> is how OAuth2 authorization model works.
> >>>
> >>> UMA leverages OAuth2 in a way that the permission ticket makes the
> client
> >>> really dumb about what it needs to access protected resources. With
> UMA,
> >>> the client will just receive a ticket and with that ticket it can
> perform
> >>> the necessary actions to make a successful authorization request to the
> >>> server.
> >>>
> >>>
> >>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
> >>>> request high level of authentication. On the implementation side it's
> about
> >>>> invoking additional parts of the authentication flow, not to initiate
> an
> >>>> required action that has nothing to do with the authentication flow.
> >>>>
> >>> Can we consider a required action as a prompt for 2nd factor, for
> >>> instance ?
> >>>
> >>>
> >>>> * Claims gathering in UMA is about asking the user for additional
> >>>> claims. AIA can be used as a poor-mans workaround to lack of claims
> >>>> gathering, but end of the day it's completely different. AIA will
> allow an
> >>>> app to invoke the action update_DOB, while claims gaterhing will
> allow the
> >>>> application to request the claim DOB.
> >>>>
> >>> Not sure, if the difference is due to updating a piece of info, both
> >>> flows request the user for the info. Is just a matter of updating or
> not
> >>> updating the info.
> >>>
> >>>
> >>>> I don't see what additional things we need to consider for something
> >>>> that is in the end very simple and can be implemented in a couple
> hours
> >>>> including tests if we don't try to make it more complicated.
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
> sthorger at redhat.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
> psilva at redhat.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
> >>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
> >>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
> >>>>>>>>>>>>>>> The user will be prompted before making an action and it's
> an action they
> >>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to
> the client.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The client is making the request and even though the user is
> >>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
> want to restrict
> >>>>>>>>>>>>>> which clients are allowed to perform such actions. That is
> what I mean by
> >>>>>>>>>>>>>> some level of authorization.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You could even consider not authenticating the client at
> all,
> >>>>>>>>>>>>>> but still allow admins to enforce which clients should be
> allowed to
> >>>>>>>>>>>>>> initiate actions on the server.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
> initiate
> >>>>>>>>>>>>> actions will work without authenticating the client.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
> >>>>>>>>>>>> discussing. This is more a validation of the client making
> the request.
> >>>>>>>>>>>> Considering that, I'm saying that you could just rely on
> client_id and
> >>>>>>>>>>>> redirect uris (the client is already authenticated and if
> doing browser
> >>>>>>>>>>>> authentication the cookie is already present) and possibly
> add some level
> >>>>>>>>>>>> of authorization to enforce which clients can perform actions
> (instead of
> >>>>>>>>>>>> just relying on the authenticated session). Redirect uris are
> really
> >>>>>>>>>>>> important because you want to make sure the redirect uri is
> valid before
> >>>>>>>>>>>> redirecting the user.
> >>>>>>>>>>>>
> >>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
> >>>>>>>>>>> redirect_uris are already being checked. It's just a standard
> OAuth flow.
> >>>>>>>>>>>
> >>>>>>>>>>> IMO that's fine as long as there's no need to limit what
> clients
> >>>>>>>>>>> can initiate actions. If that's needed then we need something
> more
> >>>>>>>>>>> complicated that properly authenticates the client, as anyone
> could just
> >>>>>>>>>>> use the client_id and redirect_uri from a different
> application to get the
> >>>>>>>>>>> action initiated (although wouldn't then have the user
> redirected back to
> >>>>>>>>>>> the app of course).
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
> >>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
> user will be
> >>>>>>>>>>>>>>>> redirected back after the action completes). But still,
> we could also add
> >>>>>>>>>>>>>>>> some level authorization.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
> >>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different
> client.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
> happens
> >>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
> back to the client
> >>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that
> the client is
> >>>>>>>>>>>>>> known and that the user will be redirected back to a valid
> URI.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
> >>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
> client wants that,
> >>>>>>>>>>>>> then they can request the user to enter a DOB, which would
> then result in
> >>>>>>>>>>>>> the DOB being available in the token.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
> >>>>>>>>>>>> Flow from UMA specs. We could probably review what is there
> and see if it
> >>>>>>>>>>>> can help to solve this problem of app initiated actions.
> >>>>>>>>>>>>
> >>>>>>>>>>> Go for it ;)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
> where
> >>>>>>>>>>>>>>> the application can request a token to initate an action.
> So flow would be:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
> >>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
> return a single use
> >>>>>>>>>>>>>>> token.
> >>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
> >>>>>>>>>>>>>>> instead of "?action=<action>" they would do
> "?action-token=<action token>"
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
> that
> >>>>>>>>>>>>>>> would get the action token before redirecting the user.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Not sure what you mean about level authorization.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
> >>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions
> may be public
> >>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for
> this, but rather
> >>>>>>>>>>>>>>>>> just rely on the OIDC flows.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
> >>>>>>>>>>>>>>>>> client?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
> >>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple
> as leveraging authz
> >>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
> Similar to what a KC
> >>>>>>>>>>>>>>>>>> extension does in regards to authentication.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
> >>>>>>>>>>>>>>>>>>> one.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
> >>>>>>>>>>>>>>>>>>> clients wanting to
> >>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
> >>>>>>>>>>>>>>>>>>> not securing it and
> >>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
> >>>>>>>>>>>>>>>>>>> anything, but welcome
> >>>>>>>>>>>>>>>>>>> others opinion on it.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
> >>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
> action
> >>>>>>>>>>>>>>>>>>> (always
> >>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined at
> >>>>>>>>>>>>>>>>>>> keycloak I see no
> >>>>>>>>>>>>>>>>>>>> need for the client/application restriction mechanism.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
> >>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are used
> >>>>>>>>>>>>>>>>>>> to prompt the user
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> perform an action associated with their account after
> >>>>>>>>>>>>>>>>>>> authenticating, but
> >>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
> >>>>>>>>>>>>>>>>>>> validate email, etc.
> >>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be manually
> >>>>>>>>>>>>>>>>>>> registered with the
> >>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
> >>>>>>>>>>>>>>>>>>> applications themselves. As an
> >>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to verify
> >>>>>>>>>>>>>>>>>>> their email, but
> >>>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>> when they use specific applications.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
> >>>>>>>>>>>>>>>>>>> account management
> >>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
> >>>>>>>>>>>>>>>>>>> require verifying the
> >>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
> >>>>>>>>>>>>>>>>>>> Application Initiated
> >>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind the
> >>>>>>>>>>>>>>>>>>> scenes is just a
> >>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
> >>>>>>>>>>>>>>>>>>> application and depending on
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
> >>>>>>>>>>>>>>>>>>> (where the user can
> >>>>>>>>>>>>>>>>>>>> select
> >>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
> >>>>>>>>>>>>>>>>>>> application).
> >>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform any
> >>>>>>>>>>>>>>>>>>> updates to the users
> >>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For example
> >>>>>>>>>>>>>>>>>>> an application
> >>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
> >>>>>>>>>>>>>>>>>>> account to a social
> >>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
> >>>>>>>>>>>>>>>>>>> link to the provider.
> >>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate these I
> >>>>>>>>>>>>>>>>>>> would like to
> >>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that applications
> >>>>>>>>>>>>>>>>>>> use to authenticate
> >>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
> >>>>>>>>>>>>>>>>>>> application would redirect
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add kc_action=<action
> >>>>>>>>>>>>>>>>>>> alias> query
> >>>>>>>>>>>>>>>>>>>>> parameter.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming all
> >>>>>>>>>>>>>>>>>>> Application Initiated
> >>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
> >>>>>>>>>>>>>>>>>>> add some mechanism in
> >>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
> >>>>>>>>>>>>>>>>>>> permitted to initiate an
> >>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
> >>>>>>>>>>>>>>>>>>> for applications.
> >>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability for
> >>>>>>>>>>>>>>>>>>> an Application
> >>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
> >>>>>>>>>>>>>>>>>>> re-authenticate prior to
> >>>>>>>>>>>>>>>>>>>> performing
> >>>>>>>>>>>>>>>>>>>>> the action. For example update password should
> >>>>>>>>>>>>>>>>>>> require the user to enter
> >>>>>>>>>>>>>>>>>>>>> the current password, while verify email should not
> >>>>>>>>>>>>>>>>>>> (as it simply sends
> >>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>> email with a link to continue).
> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>>>>>>>>>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
> >>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>>>>>>>>>>>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From pnalyvayko at agi.com  Thu Mar 21 10:42:37 2019
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Thu, 21 Mar 2019 14:42:37 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>,
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
Message-ID: <BN6PR07MB3073697C626D291E2383F746DA420@BN6PR07MB3073.namprd07.prod.outlook.com>

Hi Sven-Torben,

You may also take a look at x509 lookup SPI responsible for returning a client certificate's certificate chain. One strategy/workaround for what you are trying to do is to actually substitute the client cert with another cert with a subjectDN that you can format any way you need based on your requirements. Essentially, the approach will allow to normalize any incoming certificate's subjectDN and still rely on the existing X509 Client Cert User Authentication that comes out of the box

Cheers,

Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Marek Posolda [mposolda at redhat.com]
Sent: Thursday, March 21, 2019 5:53 AM
To: Sven-Torben Janus; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi,

The solution (a) looks quite specific to the environment and I don't
think that it will be useful to have this as a generic feature in
Keycloak.. Solution (b) looks like bit more generally useful, but still
not 100% sure about adding it to Keycloak... For the solution (b), are
you talking about the PEM String representation of the X509 certificate,
which just excludes the initial and final lines (Those with "BEGIN
CERTIFICATE" and "END CERTIFICATE" )?

Marek

On 21/03/2019 07:48, Sven-Torben Janus wrote:
> Hey all!
>
> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>
> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>
> I currently see the following options to implement a solution for this:
> 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below)
> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>
> For both approaches two different implementations come to my mind:
>
> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>
> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>
> Do you have any advice on which way to go here?
>
> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityToModelMapper.java#L57
>
> Regards
> Sven-Torben
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.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 sven-torben.janus at conciso.de  Thu Mar 21 12:18:52 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Thu, 21 Mar 2019 16:18:52 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
Message-ID: <DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>

Hi Marek,

I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
Regarding, solution b), yes that is what I thought about (with or without the initial/final lines). 

Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Marek Posolda <mposolda at redhat.com> 
Gesendet: Donnerstag, 21. M?rz 2019 10:54
An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi,

The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?

Marek

On 21/03/2019 07:48, Sven-Torben Janus wrote:
> Hey all!
>
> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>
> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>
> I currently see the following options to implement a solution for this:
> 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below)
> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>
> For both approaches two different implementations come to my mind:
>
> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>
> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>
> Do you have any advice on which way to go here?
>
> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityToModelMapper.java#L57
>
> Regards
> Sven-Torben
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From sven-torben.janus at conciso.de  Thu Mar 21 12:25:27 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Thu, 21 Mar 2019 16:25:27 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <BN6PR07MB3073697C626D291E2383F746DA420@BN6PR07MB3073.namprd07.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>,
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<BN6PR07MB3073697C626D291E2383F746DA420@BN6PR07MB3073.namprd07.prod.outlook.com>
Message-ID: <DB3PR0502MB39936238A61B8026C3190D18CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>

Hey Peter,

I am not sure, if I understand all the implication, especially when it comes to certificate validation. When I manipulate or replace the client cert, how can the existing X509 Client Cert User Authentication ensure the validity of the new/manipulated certificate then?

Regards
Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Nalyvayko, Peter <pnalyvayko at agi.com> 
Gesendet: Donnerstag, 21. M?rz 2019 15:43
An: Marek Posolda <mposolda at redhat.com>; Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: RE: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi Sven-Torben,

You may also take a look at x509 lookup SPI responsible for returning a client certificate's certificate chain. One strategy/workaround for what you are trying to do is to actually substitute the client cert with another cert with a subjectDN that you can format any way you need based on your requirements. Essentially, the approach will allow to normalize any incoming certificate's subjectDN and still rely on the existing X509 Client Cert User Authentication that comes out of the box

Cheers,

Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Marek Posolda [mposolda at redhat.com]
Sent: Thursday, March 21, 2019 5:53 AM
To: Sven-Torben Janus; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi,

The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?

Marek

On 21/03/2019 07:48, Sven-Torben Janus wrote:
> Hey all!
>
> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>
> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>
> I currently see the following options to implement a solution for this:
> 1) Writing a custom Authenticator to handle that specific situation. 
> This one would look very similar to the ootb X509 authenticator, but 
> implements either a) or b) (see below)
> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>
> For both approaches two different implementations come to my mind:
>
> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>
> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>
> Do you have any advice on which way to go here?
>
> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/authentication/authenticators/x509/UserIdentityExtra
> ctor.java
> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/authentication/authenticators/x509/UserIdentityToMod
> elMapper.java#L57
>
> Regards
> Sven-Torben
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.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 pnalyvayko at agi.com  Thu Mar 21 13:48:15 2019
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Thu, 21 Mar 2019 17:48:15 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <DB3PR0502MB39936238A61B8026C3190D18CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>,
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<BN6PR07MB3073697C626D291E2383F746DA420@BN6PR07MB3073.namprd07.prod.outlook.com>,
	<DB3PR0502MB39936238A61B8026C3190D18CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
Message-ID: <BN6PR07MB3073B764E1A8AB95C6F2A98ADA420@BN6PR07MB3073.namprd07.prod.outlook.com>

Hey Sven-Torben,

I understand your concern. The cert path validation happens during SSL handshake, so that should not be an issue. As for other information, for example Key Usage and Extended Key Usage - those fields can either be replicated into an "substitue" certificate or their validation can be turned off, again, depending on a particular use case.  Obviously, if your requirements include CRL validation or OCSP cert validation, then the suggested approach may not work for you. 

The client cert authentication is mostly concerned with mapping an existing user using the information from client certificate, cert validation is somewhat secondary (for example, the authenticator leaves the PKIX path validation to the container), and this strategy can be an alternative, rather than adding something to ootb that is specific to a particular vendor.

My $0.02
________________________________________
From: Sven-Torben Janus [sven-torben.janus at conciso.de]
Sent: Thursday, March 21, 2019 12:25 PM
To: Nalyvayko, Peter; Marek Posolda; keycloak-dev at lists.jboss.org
Subject: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hey Peter,

I am not sure, if I understand all the implication, especially when it comes to certificate validation. When I manipulate or replace the client cert, how can the existing X509 Client Cert User Authentication ensure the validity of the new/manipulated certificate then?

Regards
Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Nalyvayko, Peter <pnalyvayko at agi.com>
Gesendet: Donnerstag, 21. M?rz 2019 15:43
An: Marek Posolda <mposolda at redhat.com>; Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: RE: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi Sven-Torben,

You may also take a look at x509 lookup SPI responsible for returning a client certificate's certificate chain. One strategy/workaround for what you are trying to do is to actually substitute the client cert with another cert with a subjectDN that you can format any way you need based on your requirements. Essentially, the approach will allow to normalize any incoming certificate's subjectDN and still rely on the existing X509 Client Cert User Authentication that comes out of the box

Cheers,

Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Marek Posolda [mposolda at redhat.com]
Sent: Thursday, March 21, 2019 5:53 AM
To: Sven-Torben Janus; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values

Hi,

The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?

Marek

On 21/03/2019 07:48, Sven-Torben Janus wrote:
> Hey all!
>
> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>
> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>
> I currently see the following options to implement a solution for this:
> 1) Writing a custom Authenticator to handle that specific situation.
> This one would look very similar to the ootb X509 authenticator, but
> implements either a) or b) (see below)
> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>
> For both approaches two different implementations come to my mind:
>
> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>
> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>
> Do you have any advice on which way to go here?
>
> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/authentication/authenticators/x509/UserIdentityExtra
> ctor.java
> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/
> java/org/keycloak/authentication/authenticators/x509/UserIdentityToMod
> elMapper.java#L57
>
> Regards
> Sven-Torben
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.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 Mar 22 05:19:31 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Mar 2019 10:19:31 +0100
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
Message-ID: <ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>

Thanks for the clarification

TBH It seems to me that probably even (b) won't be very generally 
useful. Unless for example some LDAP servers store the certificate PEM 
in some standard LDAP attribute of the user? But if it's customization 
of LDAP schema specific to your environment to be able to save the 
certificate PEM in the LDAP attribute, then my vote is to not add it.

Marek

On 21/03/2019 17:18, Sven-Torben Janus wrote:
> Hi Marek,
>
> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Donnerstag, 21. M?rz 2019 10:54
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values
>
> Hi,
>
> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>
> Marek
>
> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>> Hey all!
>>
>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>
>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>
>> I currently see the following options to implement a solution for this:
>> 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below)
>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>
>> For both approaches two different implementations come to my mind:
>>
>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>
>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>
>> Do you have any advice on which way to go here?
>>
>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityExtractor.java
>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/authenticators/x509/UserIdentityToModelMapper.java#L57
>>
>> Regards
>> Sven-Torben
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From sven-torben.janus at conciso.de  Fri Mar 22 06:43:41 2019
From: sven-torben.janus at conciso.de (Sven-Torben Janus)
Date: Fri, 22 Mar 2019 10:43:41 +0000
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
Message-ID: <AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>

Hey Marek,

as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac).
IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?

Regards
Sven-Torben

-----Urspr?ngliche Nachricht-----
Von: Marek Posolda <mposolda at redhat.com> 
Gesendet: Freitag, 22. M?rz 2019 10:20
An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values

Thanks for the clarification

TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it.

Marek

On 21/03/2019 17:18, Sven-Torben Janus wrote:
> Hi Marek,
>
> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Donnerstag, 21. M?rz 2019 10:54
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; 
> keycloak-dev at lists.jboss.org
> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple 
> values
>
> Hi,
>
> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>
> Marek
>
> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>> Hey all!
>>
>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>
>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>
>> I currently see the following options to implement a solution for this:
>> 1) Writing a custom Authenticator to handle that specific situation. 
>> This one would look very similar to the ootb X509 authenticator, but 
>> implements either a) or b) (see below)
>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>
>> For both approaches two different implementations come to my mind:
>>
>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>
>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>
>> Do you have any advice on which way to go here?
>>
>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main
>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityExt
>> ractor.java
>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main
>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityToM
>> odelMapper.java#L57
>>
>> Regards
>> Sven-Torben
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



From psilva at redhat.com  Fri Mar 22 06:50:03 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 22 Mar 2019 11:50:03 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAfTD4VxJ9EmO1SniJ=csYJCKR4=S__+JGtZvE34UOhMPQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAM01paboUsvHA_WR3TC455ByZV4V0m7r7JDKsi2xDvpZCDGZ-Q@mail.gmail.com>
	<CAJgngAcKG7k7q_Vzb+Pj81WSeKhKAHqHY4OgLtr9tDEVCnp0Fg@mail.gmail.com>
	<CAJrcDBfmhAvFqyj6rMh7iDpFCGLQOoXmV-v_paN54ApyJj6jBw@mail.gmail.com>
	<CAJgngAdBrc5uTq6HJ65vTV-FB18d-E_NdnJwJqPdkn3fA2yEtg@mail.gmail.com>
	<CAJrcDBepqeH6pseaVYBsqphO+_tJB0BguetmY0tM8n=4rfQYfw@mail.gmail.com>
	<CAJgngAc5oc3fszbQu9+wyQpGQtHNxfAm1UnkJ0df_kGJs6eqJg@mail.gmail.com>
	<CAJrcDBfKW8Mz+u98twKgb7Ud8-DRSu0zV+-37gRrTj8m7-8ohA@mail.gmail.com>
	<CAJgngAexb76N5=73DAV+iaidb6CVSThr+DVDSOeakZjHkRuHDQ@mail.gmail.com>
	<CAJrcDBfMABjSE5U-2Y_K8qngb6kVZ-RDfFfv_6AYqNsLVWaFXw@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<CAJgngAfTD4VxJ9EmO1SniJ=csYJCKR4=S__+JGtZvE34UOhMPQ@mail.gmail.com>
Message-ID: <CAJrcDBdqSr7HKmeWW9KVxOqq4RPVKObjg6TUkDy7PaUmtWjxwQ@mail.gmail.com>

Just one last thing ... Step-up can be even simpler if you just use the amr
claim to check for the authentication method.Of course, that would be tied
with the implicit level of trust agreed between clients and AS.

Em qui, 21 de mar de 2019 14:05, Stian Thorgersen <sthorger at redhat.com>
escreveu:

> I'm still not seeing a concrete proposal from you and as I see it trying
> to have AIA solve step-up and claims gathering is a complete broken idea
> and will just result in it being overly complex to implement and use.
>
> On Thu, 21 Mar 2019 at 13:05, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> In addition to everything you said.
>>
>> * It is not only about making changes to account, but updating tokens
>> with information from required actions, which not necessarily need to be
>> persisted.
>>
>
> Not needed for the use-case I mentioned. Besides if the action makes
> additional information available about the user that can be mapped into the
> token with mappers and would be available in the updated tokens the app
> receives after the action has been completed.
>
>
>>
>> * For back-end applications, we could also associate these required
>> actions with scopes. If we could have a required action as
>> "Re-authenticate" or "Provide 2nd factor", that would also help with
>> step-up authentication. As an alternative to OIDC acr related
>> parameters/claims. I don't think it makes sense to bring to the client
>> concerns that are really tied to the scopes of a resource server. As I
>> said, clients should ask for scopes and Keycloak should do whatever is
>> necessary to grant these (via consent, via additional steps/actions).
>> Consider what you mentioned at the end of your design document at "Require
>> Re-Authentication". Couldn't we leverage AIA for step-up and ask the user
>> for a more stronger credential ?
>>
>
> Using this for step-up is just completely broken idea. Step-up
> authentication is simple. Application requests level=0 initially, Keycloak
> authenticates user to level=1, later application requests level=1, Keycloak
> authenticates to level=1. The application should not have to ask for a
> specific action to be done to step the authentication up. It's up to
> Keycloak and how the user is configured to take it to the level the app
> wants.
>
> AIA != Step-up authentication
>
>
>
>>
>> * Claims gathering flow is simple. The Keycloak server would return the
>> endpoint to where the client should redirect the user. After obtaining
>> information from the user, Keycloak would issue a ticket (instead of code).
>> The endpoint returned by Keycloak would contain the action associated with
>> a resource. The endpoint could be the same as what you are using for AIA.
>>
>
> Endpoint I'm using for AIA is the auth endpoint. It's not a new endpoint,
> just one query parameter added. It's asking for a specific action to be
> performed (register OTP), not asking for additional claims (I need DOB).
> From briefly reading UMA claims gathering flow it's a completely new
> endpoint and has a completely different flow.
>
> AIA != claims gathering
>
>
>>
>>
>>
>>
>>
>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Pedro,
>>>
>>> I really don't understand what your points are and what you propose we
>>> do here.
>>>
>>> The use-case we're addressing is the following:
>>>
>>> As a user I would like to initiate an action associated with my account
>>> through a front-end application so that I can make changes to my account,
>>> for example to register a WebAuthn security key with my account.
>>>
>>> Further, we want an action to be implemented once and re-usable in
>>> login/registration flows as well as from applications managing user
>>> accounts, incuding our new account console. That means our new account
>>> console needs to be able to invoke an action in the login flow, otherwise
>>> we would have to implement actions as react/rest also.
>>>
>>> Now the solution I have proposed is simple. It allows an application to
>>> request an action being invoked after the user has authenticated. Think of
>>> it as a "required action" on-demand. It can be implemented with a few lines
>>> of code and easily tested. It is very easy to use as it just means adding
>>> an extra query param to the login flows, which makes it very easy to use
>>> both for confidential and non-confidential clients.
>>>
>>> It is not trying to cover claims gathering use-case from UMA. I see no
>>> connection to this and step-up authentication. These both already have
>>> clearly defined protocols. Neither can be used to address the above
>>> use-case.
>>>
>>> So please come with a concrete proposal as I have no clue what your
>>> objections are.
>>>
>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>>>
>>>>>>>>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>>>
>>>>>>>>>>> From that it does a get including the ticket as a query
>>>>>>>>>>> parameter. I don't like the idea of sending tickets as query params as they
>>>>>>>>>>> could be logged. For the application initiated action it would have to be
>>>>>>>>>>> an ID token sent as the ticket. Or as I mentioned before perhaps we have a
>>>>>>>>>>> way of creating a ticket that can only be used to initiate an action.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>>>> token and, considering browser flow, there is a cookie that can be used by
>>>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the identity cookie has the user session and from it we can
>>>>>>>> check whether or not the client initiating the action (client_id) has a
>>>>>>>> authenticated client session, no ?
>>>>>>>>
>>>>>>>
>>>>>>> That only proves that the client_id belongs to a client that has
>>>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>>>
>>>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>>>> required.
>>>>>>>
>>>>>>
>>>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>>>> on behalf of the user. If the client is already acting on behalf of a user,
>>>>>> we don't need to authenticate it.
>>>>>>
>>>>>
>>>>> That's not correct. All we know is that a client with the same
>>>>> client_id has obtained a token. Anyone can use the same client_id to
>>>>> initiate an action.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>>>
>>>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>>>> initiate actions
>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>>>> everyone then no need for a ticket
>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>>>
>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>>>
>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>>>> redirect does
>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>>>>>>>>>>> endpoint using an id token as bearer token
>>>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>>>> for clients that can initiate actions and map this into the id token.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not sure ...
>>>>>>>>>>
>>>>>>>>>> If you think about it, the part interested in obtaining the
>>>>>>>>>> claims after an action is completed is not the client but the audience of
>>>>>>>>>> the token, the resource server. In this case, the UMA approach seems more
>>>>>>>>>> appropriate because the resource server is in control about what actions
>>>>>>>>>> the client should initiate in order to fulfill the constraints imposed by
>>>>>>>>>> the resource server to access its protected resources. Where these
>>>>>>>>>> constraints could be a DOB in the token or a higher security level.
>>>>>>>>>>
>>>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>>>
>>>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance and just
>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Perhaps there's a case for that, but that would be claims
>>>>>>>>> gathering, not application initiated actions.
>>>>>>>>>
>>>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>>>> actions for the user account into their own GUIs, and as such should be a
>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't have any
>>>>>>>>> flows between app and service, but rather just allows the app to get the
>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think claims gathering and AIA are pretty much the same thing.
>>>>>>>> Both are querying the user for additional information. Despite if you are
>>>>>>>> initiating an action to request user's DOB or update a password, they are
>>>>>>>> steps that the user must perform in order to enrich its security context
>>>>>>>> and be able to continue using both client and resource server.
>>>>>>>>
>>>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>>>> too. You would still solve the original problem from your design document
>>>>>>>> as defined in the motivation section. While you would also help with
>>>>>>>> step-up authentication and UMA claims gathering. Another point is related
>>>>>>>> to the party interested in the action. Is it the client or the resource
>>>>>>>> server (the API)?
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> If the client (which honestly I don't see much use as most apps
>>>>>>>> seem to be a combination of front-end + back-end, where the functionality
>>>>>>>> is provided by the back-end and protected by a bearer token) then you may
>>>>>>>> just consider passing the "kc_action" parameter and have the action
>>>>>>>> initiated.
>>>>>>>>
>>>>>>>> If the resource server, you could associate the required actions
>>>>>>>> with the scopes. So when a client requests a specific scope, Keycloak will
>>>>>>>> start the action(s) and query the user for some information prior to
>>>>>>>> issuing the access token.
>>>>>>>>
>>>>>>>> Still, if the resource server, the resource server could respond to
>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info, then the
>>>>>>>> client will just redirect the user to the location provided in the response
>>>>>>>> to initiate the actions.
>>>>>>>>
>>>>>>>
>>>>>>> I don't understand what your point is or what you are proposing here.
>>>>>>>
>>>>>>
>>>>>> And I do understand your point of view. I just think that it can do
>>>>>> much more than address new account management console requirements.
>>>>>>
>>>>>> Based on your design document, I understand what you described in the
>>>>>> Motivation section. But again, instead of considering the "two things" that
>>>>>> originated the idea behind AIA, I think we can take the opportunity and do
>>>>>> much more. As they seem related to me. Especially after your DOB example.
>>>>>>
>>>>>
>>>>> I don't see the additional use-cases you are mentioning as related at
>>>>> all.
>>>>>
>>>>
>>>> How it is not related ? The audience of the information gathered during
>>>> the AIA does impact where the token with the information will be used. If I
>>>> need a DOB to access some page in my front-end, this is one thing. If I
>>>> need DOB to access some resource protected by a resource server it is
>>>> another thing. Both require tokens with different audiences, the former
>>>> will probably be an ID Token where the latter the access token.
>>>>
>>>> In OAuth2 the scopes represent the permissions to access protected
>>>> resources. Thus, it does make sense to have required actions that can
>>>> challenge a user when requesting scopes. Considering your DOB example, if
>>>> my client wants to access resource /api/age/check why you want the client
>>>> to request kc_action=dob if the scope "dob" is what he needs to access the
>>>> API ? Otherwise, you are making the client aware of things that are really
>>>> related to the resource server. It is OK the client ask for scope "age", it
>>>> is how OAuth2 authorization model works.
>>>>
>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>>>> client really dumb about what it needs to access protected resources. With
>>>> UMA, the client will just receive a ticket and with that ticket it can
>>>> perform the necessary actions to make a successful authorization request to
>>>> the server.
>>>>
>>>>
>>>>>
>>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>>>> request high level of authentication. On the implementation side it's about
>>>>> invoking additional parts of the authentication flow, not to initiate an
>>>>> required action that has nothing to do with the authentication flow.
>>>>>
>>>>
>>>> Can we consider a required action as a prompt for 2nd factor, for
>>>> instance ?
>>>>
>>>>
>>>>>
>>>>> * Claims gathering in UMA is about asking the user for additional
>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>>>> gathering, but end of the day it's completely different. AIA will allow an
>>>>> app to invoke the action update_DOB, while claims gaterhing will allow the
>>>>> application to request the claim DOB.
>>>>>
>>>>
>>>> Not sure, if the difference is due to updating a piece of info, both
>>>> flows request the user for the info. Is just a matter of updating or not
>>>> updating the info.
>>>>
>>>>
>>>>>
>>>>> I don't see what additional things we need to consider for something
>>>>> that is in the end very simple and can be implemented in a couple hours
>>>>> including tests if we don't try to make it more complicated.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>>>> The user will be prompted before making an action and it's an action they
>>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to the client.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may want to restrict
>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That is what I mean by
>>>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You could even consider not authenticating the client at
>>>>>>>>>>>>>>> all, but still allow admins to enforce which clients should be allowed to
>>>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>>>>>>>>>>>>>> initiate actions will work without authenticating the client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>>>> discussing. This is more a validation of the client making the request.
>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on client_id and
>>>>>>>>>>>>> redirect uris (the client is already authenticated and if doing browser
>>>>>>>>>>>>> authentication the cookie is already present) and possibly add some level
>>>>>>>>>>>>> of authorization to enforce which clients can perform actions (instead of
>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris are really
>>>>>>>>>>>>> important because you want to make sure the redirect uri is valid before
>>>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>>>> redirect_uris are already being checked. It's just a standard OAuth flow.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>>>>>>>>>>>> clients can initiate actions. If that's needed then we need something more
>>>>>>>>>>>> complicated that properly authenticates the client, as anyone could just
>>>>>>>>>>>> use the client_id and redirect_uri from a different application to get the
>>>>>>>>>>>> action initiated (although wouldn't then have the user redirected back to
>>>>>>>>>>>> the app of course).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the user will be
>>>>>>>>>>>>>>>>> redirected back after the action completes). But still, we could also add
>>>>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different client.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>>>>>>>>>>>>>>> happens after the user performs an action. Is he/her redirected back to the
>>>>>>>>>>>>>>> client ? If so, client_id + redirect_uri do work to make sure that the
>>>>>>>>>>>>>>> client is known and that the user will be redirected back to a valid URI.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the client wants that,
>>>>>>>>>>>>>> then they can request the user to enter a DOB, which would then result in
>>>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there and see if it
>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Go for it ;)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>>>>>>>>>>>>>>>> where the application can request a token to initate an action. So flow
>>>>>>>>>>>>>>>> would be:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would return a single use
>>>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do "?action-token=<action token>"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
>>>>>>>>>>>>>>>> that would get the action token before redirecting the user.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions may be public
>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for this, but rather
>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple as leveraging authz
>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients. Similar to what a KC
>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> > Since there is no "silent" application initiated
>>>>>>>>>>>>>>>>>>>> action (always
>>>>>>>>>>>>>>>>>>>> > prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>>>>> > need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > Keycloak currently has required actions that are
>>>>>>>>>>>>>>>>>>>> used to prompt the user
>>>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>>>> > > perform an action associated with their account
>>>>>>>>>>>>>>>>>>>> after authenticating, but
>>>>>>>>>>>>>>>>>>>> > > prior to being redirected to the application.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>>>>> > > users account, but can not be initiated by
>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>>>>> > > example it may not be required by all users to
>>>>>>>>>>>>>>>>>>>> verify their email, but
>>>>>>>>>>>>>>>>>>>> > only
>>>>>>>>>>>>>>>>>>>> > > when they use specific applications.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>>>>> > > console. Examples: updating email address should
>>>>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>>>>> > > email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>> > > Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>>>>> > > Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>>>> application and depending on
>>>>>>>>>>>>>>>>>>>> > the
>>>>>>>>>>>>>>>>>>>> > > action may be optional for the user to complete
>>>>>>>>>>>>>>>>>>>> (where the user can
>>>>>>>>>>>>>>>>>>>> > select
>>>>>>>>>>>>>>>>>>>> > > cancel which would return the user back to the
>>>>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>>>>> > > account without prompting the user first. For
>>>>>>>>>>>>>>>>>>>> example an application
>>>>>>>>>>>>>>>>>>>> > > initiated action that is used to link an existing
>>>>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>>>>> > > provider should ask the user first if they want to
>>>>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > To make it easy for applications to integrate these
>>>>>>>>>>>>>>>>>>>> I would like to
>>>>>>>>>>>>>>>>>>>> > > leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>>>>> > > users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>>>>> > to
>>>>>>>>>>>>>>>>>>>> > > the authentication endpoint and add
>>>>>>>>>>>>>>>>>>>> kc_action=<action alias> query
>>>>>>>>>>>>>>>>>>>> > > parameter.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>> > > Actions always prompt the user first do we need to
>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>>>>>>>>>>>>>>>>>> > > place to restrict what clients/applications are
>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>>>>> > > action? Requiring that would make it harder to use
>>>>>>>>>>>>>>>>>>>> for applications.
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> > > One thing I would also like to add is the ability
>>>>>>>>>>>>>>>>>>>> for an Application
>>>>>>>>>>>>>>>>>>>> > > Initiated Action to require the user to
>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>>>>> > performing
>>>>>>>>>>>>>>>>>>>> > > the action. For example update password should
>>>>>>>>>>>>>>>>>>>> require the user to enter
>>>>>>>>>>>>>>>>>>>> > > the current password, while verify email should not
>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>>>>> > an
>>>>>>>>>>>>>>>>>>>> > > email with a link to continue).
>>>>>>>>>>>>>>>>>>>> > > _______________________________________________
>>>>>>>>>>>>>>>>>>>> > > keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>> > > keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>>>>>>> https://lists.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 Mar 22 07:01:51 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Mar 2019 12:01:51 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
Message-ID: <48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>

I am sorry to join this so late.

My concern is, that in the design, it was mentioned that consent will be 
always required from the user. I understand that this simplifies the 
flow as it's more secure and not need to authenticate the client. 
However from the usability perspective, it doesn't look so nice to me.

For example assume that in the application, the user just clicked on the 
button "Link my account with Facebook" . Then after login with Facebook, 
he will see another splash screen like "Application XY wants to link 
your account with Facebook", which he needs to confirm. It may be 
especially bad for usability in this case with linking social accounts, 
as user may see one splash screen shown by Facebook "Application 
keycloak wants to access your Facebook profile and email" and then 
immediately another splash screen shown by Keycloak "Application Foo 
wants to link your account with Facebook" .

Maybe I am wrong, but my guess is, that our users will very quickly come 
with requirement "Can I ommit to show the splash screen?" . It is bit 
similar to the "Consent Required" switch, which I guess most people have 
OFF for their clients. So IMO I would rather count with this from the 
beginning and count with the fact, that we will need to ommit consent 
screen and hence verify client.

With regards to this, It seems that we may need also to specify if 
client is:
- Allowed to initiate action
- Allowed to initate action with the consent required
- Allowed to initate action with no-consent required
Maybe the "Consent required" switch can be on instead on the action 
itself, but the will still need to restrict if client is allowed or not 
to perform the action.

With regards to the flow, I suggest that KC will require full 
OIDC/OAuth2 flow. In other words, when KC redirects back to the client, 
the client will be required to send code-to-token request. And the 
action (EG. Keycloak user linked with Facebook) is done *after* the 
whole flow (including code-to-token flow) is finished. That should be 
sufficient to verify the client and at the same time, it will allow us 
to add some more things to tokens (EG. some facebook details) . Downside 
is, that it will be harder to implement though as the SPI will likely 
need another callback after code-to-token flow to "finish" the action...

Last thing, I was thinking about using "scope" parameter to reference 
those actions instead of have proprietary "kc_action" thing. The we 
don't need any extensions of OIDC. It may simplify things like consents 
etc. Also client will be able to have something similar like we have in 
"Client Scopes" tab - the list of action, which he is allowed to 
initiate. But I am not sure about this last point and maybe it's better 
to keep things separated...

Marek




On 21/03/2019 14:07, Pedro Igor Silva wrote:
> Sure, I'm not against the initial design/scope. Just tried to make comments
> about other aspects that, to me, are related or how it can be leveraged to
> also achieve other things.
>
> So, what Stian plans mentioned in one of his replies is fine for me.
>
> On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com> wrote:
>
>> Pedro,
>>
>> My only concern is getting this nailed down so we can move forward with
>> the new account console.
>>
>> It sounds like Stian's proposal is simpler, but covers fewer use cases.
>> Is that correct?
>>
>> Would it be practical to implement Stian's plan and then implement your
>> proposal at a later date?
>>
>> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>> In addition to everything you said.
>>>
>>> * It is not only about making changes to account, but updating tokens
>> with
>>> information from required actions, which not necessarily need to be
>>> persisted.
>>>
>>> * For back-end applications, we could also associate these required
>> actions
>>> with scopes. If we could have a required action as "Re-authenticate" or
>>> "Provide 2nd factor", that would also help with step-up authentication.
>> As
>>> an alternative to OIDC acr related parameters/claims. I don't think it
>>> makes sense to bring to the client concerns that are really tied to the
>>> scopes of a resource server. As I said, clients should ask for scopes and
>>> Keycloak should do whatever is necessary to grant these (via consent, via
>>> additional steps/actions). Consider what you mentioned at the end of your
>>> design document at "Require Re-Authentication". Couldn't we leverage AIA
>>> for step-up and ask the user for a more stronger credential ?
>>>
>>> * Claims gathering flow is simple. The Keycloak server would return the
>>> endpoint to where the client should redirect the user. After obtaining
>>> information from the user, Keycloak would issue a ticket (instead of
>> code).
>>> The endpoint returned by Keycloak would contain the action associated
>> with
>>> a resource. The endpoint could be the same as what you are using for AIA.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Pedro,
>>>>
>>>> I really don't understand what your points are and what you propose we
>> do
>>>> here.
>>>>
>>>> The use-case we're addressing is the following:
>>>>
>>>> As a user I would like to initiate an action associated with my account
>>>> through a front-end application so that I can make changes to my
>> account,
>>>> for example to register a WebAuthn security key with my account.
>>>>
>>>> Further, we want an action to be implemented once and re-usable in
>>>> login/registration flows as well as from applications managing user
>>>> accounts, incuding our new account console. That means our new account
>>>> console needs to be able to invoke an action in the login flow,
>> otherwise
>>>> we would have to implement actions as react/rest also.
>>>>
>>>> Now the solution I have proposed is simple. It allows an application to
>>>> request an action being invoked after the user has authenticated. Think
>> of
>>>> it as a "required action" on-demand. It can be implemented with a few
>> lines
>>>> of code and easily tested. It is very easy to use as it just means
>> adding
>>>> an extra query param to the login flows, which makes it very easy to use
>>>> both for confidential and non-confidential clients.
>>>>
>>>> It is not trying to cover claims gathering use-case from UMA. I see no
>>>> connection to this and step-up authentication. These both already have
>>>> clearly defined protocols. Neither can be used to address the above
>>>> use-case.
>>>>
>>>> So please come with a concrete proposal as I have no clue what your
>>>> objections are.
>>>>
>>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>> sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>> sthorger at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <psilva at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Is it this stuff you're thinking about:
>>>>>>>>>>>>
>>>>>>>>>>>>
>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>>>>>>>>>>   From that it does a get including the ticket as a query
>> parameter.
>>>>>>>>>>>> I don't like the idea of sending tickets as query params as
>> they could be
>>>>>>>>>>>> logged. For the application initiated action it would have to
>> be an ID
>>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we
>> have a way of
>>>>>>>>>>>> creating a ticket that can only be used to initiate an action.
>>>>>>>>>>>>
>>>>>>>>>>> Why you need to send the id token if the client already got an id
>>>>>>>>>>> token and, considering browser flow, there is a cookie that can
>> be used by
>>>>>>>>>>> Keycloak to identify the client/user ?
>>>>>>>>>>>
>>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>>>>>>>>
>>>>>>>>> But the identity cookie has the user session and from it we can
>> check
>>>>>>>>> whether or not the client initiating the action (client_id) has a
>>>>>>>>> authenticated client session, no ?
>>>>>>>>>
>>>>>>>> That only proves that the client_id belongs to a client that has
>>>>>>>> obtained a token. It doesn't authenticate the client in any way.
>>>>>>>>
>>>>>>>> Q- Why is authentication of the client required? IMO it is not
>>>>>>>> required.
>>>>>>>>
>>>>>>> Sure, but the client obtained token and is authenticated, thus acting
>>>>>>> on behalf of the user. If the client is already acting on behalf of
>> a user,
>>>>>>> we don't need to authenticate it.
>>>>>>>
>>>>>> That's not correct. All we know is that a client with the same
>> client_id
>>>>>> has obtained a token. Anyone can use the same client_id to initiate an
>>>>>> action.
>>>>>>
>>>>>>
>>>>>>>>>>>> Perhaps what we could do is:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. By default any application can initiate an action
>>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
>>>>>>>>>>>> sort, just a regular oauth flow
>>>>>>>>>>>> 2. Later add support if demand to limit what applications can
>>>>>>>>>>>> initiate actions
>>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>>>>>>>>>>> everyone then no need for a ticket
>>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>>>>>>>>>> applications we would need some form of authentication.
>>>>>>>>>>>>
>>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>>>>>>>>>>
>>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA claim
>>>>>>>>>>>> redirect does
>>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>> endpoint
>>>>>>>>>>>> using an id token as bearer token
>>>>>>>>>>>> c. Add a note into client session with a initiate action ticket
>>>>>>>>>>>> for clients that can initiate actions and map this into the id
>> token.
>>>>>>>>>>> Not sure ...
>>>>>>>>>>>
>>>>>>>>>>> If you think about it, the part interested in obtaining the
>> claims
>>>>>>>>>>> after an action is completed is not the client but the audience
>> of the
>>>>>>>>>>> token, the resource server. In this case, the UMA approach seems
>> more
>>>>>>>>>>> appropriate because the resource server is in control about what
>> actions
>>>>>>>>>>> the client should initiate in order to fulfill the constraints
>> imposed by
>>>>>>>>>>> the resource server to access its protected resources. Where
>> these
>>>>>>>>>>> constraints could be a DOB in the token or a higher security
>> level.
>>>>>>>>>>> The app initiating actions in the server is not the goal, but the
>>>>>>>>>>> tool to obtain additional claims from the server ...
>>>>>>>>>>>
>>>>>>>>>>> However, for some applications acting as both client and resource
>>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance
>> and just
>>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>>>>>>>>>
>>>>>>>>>> Perhaps there's a case for that, but that would be claims
>> gathering,
>>>>>>>>>> not application initiated actions.
>>>>>>>>>>
>>>>>>>>>> Application initiated actions are more a tool for folks to add
>>>>>>>>>> actions for the user account into their own GUIs, and as such
>> should be a
>>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
>> have any
>>>>>>>>>> flows between app and service, but rather just allows the app to
>> get the
>>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>>>>>>>>
>>>>>>>>> I think claims gathering and AIA are pretty much the same thing.
>> Both
>>>>>>>>> are querying the user for additional information. Despite if you
>> are
>>>>>>>>> initiating an action to request user's DOB or update a password,
>> they are
>>>>>>>>> steps that the user must perform in order to enrich its security
>> context
>>>>>>>>> and be able to continue using both client and resource server.
>>>>>>>>>
>>>>>>>>> The point I'm trying to make is that AIA can solve other problems
>>>>>>>>> too. You would still solve the original problem from your design
>> document
>>>>>>>>> as defined in the motivation section. While you would also help
>> with
>>>>>>>>> step-up authentication and UMA claims gathering. Another point is
>> related
>>>>>>>>> to the party interested in the action. Is it the client or the
>> resource
>>>>>>>>> server (the API)?
>>>>>>>>>
>>>>>>>>> If the client (which honestly I don't see much use as most apps
>> seem
>>>>>>>>> to be a combination of front-end + back-end, where the
>> functionality is
>>>>>>>>> provided by the back-end and protected by a bearer token) then you
>> may just
>>>>>>>>> consider passing the "kc_action" parameter and have the action
>> initiated.
>>>>>>>>> If the resource server, you could associate the required actions
>> with
>>>>>>>>> the scopes. So when a client requests a specific scope, Keycloak
>> will start
>>>>>>>>> the action(s) and query the user for some information prior to
>> issuing the
>>>>>>>>> access token.
>>>>>>>>>
>>>>>>>>> Still, if the resource server, the resource server could respond to
>>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
>> then the
>>>>>>>>> client will just redirect the user to the location provided in the
>> response
>>>>>>>>> to initiate the actions.
>>>>>>>>>
>>>>>>>> I don't understand what your point is or what you are proposing
>> here.
>>>>>>> And I do understand your point of view. I just think that it can do
>>>>>>> much more than address new account management console requirements.
>>>>>>>
>>>>>>> Based on your design document, I understand what you described in the
>>>>>>> Motivation section. But again, instead of considering the "two
>> things" that
>>>>>>> originated the idea behind AIA, I think we can take the opportunity
>> and do
>>>>>>> much more. As they seem related to me. Especially after your DOB
>> example.
>>>>>> I don't see the additional use-cases you are mentioning as related at
>>>>>> all.
>>>>>>
>>>>> How it is not related ? The audience of the information gathered during
>>>>> the AIA does impact where the token with the information will be used.
>> If I
>>>>> need a DOB to access some page in my front-end, this is one thing. If I
>>>>> need DOB to access some resource protected by a resource server it is
>>>>> another thing. Both require tokens with different audiences, the former
>>>>> will probably be an ID Token where the latter the access token.
>>>>>
>>>>> In OAuth2 the scopes represent the permissions to access protected
>>>>> resources. Thus, it does make sense to have required actions that can
>>>>> challenge a user when requesting scopes. Considering your DOB example,
>> if
>>>>> my client wants to access resource /api/age/check why you want the
>> client
>>>>> to request kc_action=dob if the scope "dob" is what he needs to access
>> the
>>>>> API ? Otherwise, you are making the client aware of things that are
>> really
>>>>> related to the resource server. It is OK the client ask for scope
>> "age", it
>>>>> is how OAuth2 authorization model works.
>>>>>
>>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>> client
>>>>> really dumb about what it needs to access protected resources. With
>> UMA,
>>>>> the client will just receive a ticket and with that ticket it can
>> perform
>>>>> the necessary actions to make a successful authorization request to the
>>>>> server.
>>>>>
>>>>>
>>>>>> * Step-up authentication has already clear parameters in OIDC/OAuth to
>>>>>> request high level of authentication. On the implementation side it's
>> about
>>>>>> invoking additional parts of the authentication flow, not to initiate
>> an
>>>>>> required action that has nothing to do with the authentication flow.
>>>>>>
>>>>> Can we consider a required action as a prompt for 2nd factor, for
>>>>> instance ?
>>>>>
>>>>>
>>>>>> * Claims gathering in UMA is about asking the user for additional
>>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>>>>>> gathering, but end of the day it's completely different. AIA will
>> allow an
>>>>>> app to invoke the action update_DOB, while claims gaterhing will
>> allow the
>>>>>> application to request the claim DOB.
>>>>>>
>>>>> Not sure, if the difference is due to updating a piece of info, both
>>>>> flows request the user for the info. Is just a matter of updating or
>> not
>>>>> updating the info.
>>>>>
>>>>>
>>>>>> I don't see what additional things we need to consider for something
>>>>>> that is in the end very simple and can be implemented in a couple
>> hours
>>>>>> including tests if we don't try to make it more complicated.
>>>>>>
>>>>>>
>>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>> sthorger at redhat.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>> psilva at redhat.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why do you think authentication/authorization is required?
>>>>>>>>>>>>>>>>> The user will be prompted before making an action and it's
>> an action they
>>>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed to
>> the client.
>>>>>>>>>>>>>>>> The client is making the request and even though the user is
>>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
>> want to restrict
>>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That is
>> what I mean by
>>>>>>>>>>>>>>>> some level of authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You could even consider not authenticating the client at
>> all,
>>>>>>>>>>>>>>>> but still allow admins to enforce which clients should be
>> allowed to
>>>>>>>>>>>>>>>> initiate actions on the server.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>> initiate
>>>>>>>>>>>>>>> actions will work without authenticating the client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>>>>>>>>>>>> discussing. This is more a validation of the client making
>> the request.
>>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
>> client_id and
>>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
>> doing browser
>>>>>>>>>>>>>> authentication the cookie is already present) and possibly
>> add some level
>>>>>>>>>>>>>> of authorization to enforce which clients can perform actions
>> (instead of
>>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris are
>> really
>>>>>>>>>>>>>> important because you want to make sure the redirect uri is
>> valid before
>>>>>>>>>>>>>> redirecting the user.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>>>>>>>>>>> redirect_uris are already being checked. It's just a standard
>> OAuth flow.
>>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>> clients
>>>>>>>>>>>>> can initiate actions. If that's needed then we need something
>> more
>>>>>>>>>>>>> complicated that properly authenticates the client, as anyone
>> could just
>>>>>>>>>>>>> use the client_id and redirect_uri from a different
>> application to get the
>>>>>>>>>>>>> action initiated (although wouldn't then have the user
>> redirected back to
>>>>>>>>>>>>> the app of course).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
>>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
>> user will be
>>>>>>>>>>>>>>>>>> redirected back after the action completes). But still,
>> we could also add
>>>>>>>>>>>>>>>>>> some level authorization.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
>>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different
>> client.
>>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>> happens
>>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
>> back to the client
>>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure that
>> the client is
>>>>>>>>>>>>>>>> known and that the user will be redirected back to a valid
>> URI.
>>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new tokens.
>>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
>> client wants that,
>>>>>>>>>>>>>>> then they can request the user to enter a DOB, which would
>> then result in
>>>>>>>>>>>>>>> the DOB being available in the token.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This flow seems very closely related with the Claims Gathering
>>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there
>> and see if it
>>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Go for it ;)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>> where
>>>>>>>>>>>>>>>>> the application can request a token to initate an action.
>> So flow would be:
>>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token as
>>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>> return a single use
>>>>>>>>>>>>>>>>> token.
>>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>> "?action-token=<action token>"
>>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
>> that
>>>>>>>>>>>>>>>>> would get the action token before redirecting the user.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients and
>>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions
>> may be public
>>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol for
>> this, but rather
>>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate the
>>>>>>>>>>>>>>>>>>> client?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple
>> as leveraging authz
>>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>> Similar to what a KC
>>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on this
>>>>>>>>>>>>>>>>>>>>> one.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of the
>>>>>>>>>>>>>>>>>>>>> clients wanting to
>>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable about
>>>>>>>>>>>>>>>>>>>>> not securing it and
>>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
>> action
>>>>>>>>>>>>>>>>>>>>> (always
>>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined at
>>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction mechanism.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are used
>>>>>>>>>>>>>>>>>>>>> to prompt the user
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account after
>>>>>>>>>>>>>>>>>>>>> authenticating, but
>>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be manually
>>>>>>>>>>>>>>>>>>>>> registered with the
>>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to verify
>>>>>>>>>>>>>>>>>>>>> their email, but
>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>>>>>>>>>>>>>>>>>>>>> account management
>>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>>>>>>>>>>>>>>>>>>>>> require verifying the
>>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind the
>>>>>>>>>>>>>>>>>>>>> scenes is just a
>>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>>>>>>>>>>>>>>>>>>>>> application and depending on
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>>>>>>>>>>>>>>>>>>>>> (where the user can
>>>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>>>>>>>>>>>>>>>>>>>>> application).
>>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform any
>>>>>>>>>>>>>>>>>>>>> updates to the users
>>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For example
>>>>>>>>>>>>>>>>>>>>> an application
>>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
>>>>>>>>>>>>>>>>>>>>> account to a social
>>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
>>>>>>>>>>>>>>>>>>>>> link to the provider.
>>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate these I
>>>>>>>>>>>>>>>>>>>>> would like to
>>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that applications
>>>>>>>>>>>>>>>>>>>>> use to authenticate
>>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>>>>>>>>>>>>>>>>>>>>> application would redirect
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add kc_action=<action
>>>>>>>>>>>>>>>>>>>>> alias> query
>>>>>>>>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming all
>>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
>>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
>>>>>>>>>>>>>>>>>>>>> for applications.
>>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability for
>>>>>>>>>>>>>>>>>>>>> an Application
>>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>>>>>>>>>>>>>>>>>>>> performing
>>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>>>>>>>>>>>>>>>>>>>>> require the user to enter
>>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should not
>>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>>>>>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>>>>>>>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Fri Mar 22 07:42:17 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Mar 2019 12:42:17 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
Message-ID: <CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>

On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com> wrote:

> I am sorry to join this so late.
>
> My concern is, that in the design, it was mentioned that consent will be
> always required from the user. I understand that this simplifies the
> flow as it's more secure and not need to authenticate the client.
> However from the usability perspective, it doesn't look so nice to me.
>
> For example assume that in the application, the user just clicked on the
> button "Link my account with Facebook" . Then after login with Facebook,
> he will see another splash screen like "Application XY wants to link
> your account with Facebook", which he needs to confirm. It may be
> especially bad for usability in this case with linking social accounts,
> as user may see one splash screen shown by Facebook "Application
> keycloak wants to access your Facebook profile and email" and then
> immediately another splash screen shown by Keycloak "Application Foo
> wants to link your account with Facebook" .
>
> Maybe I am wrong, but my guess is, that our users will very quickly come
> with requirement "Can I ommit to show the splash screen?" . It is bit
> similar to the "Consent Required" switch, which I guess most people have
> OFF for their clients. So IMO I would rather count with this from the
> beginning and count with the fact, that we will need to ommit consent
> screen and hence verify client.
>
> With regards to this, It seems that we may need also to specify if
> client is:
> - Allowed to initiate action
> - Allowed to initate action with the consent required
> - Allowed to initate action with no-consent required
> Maybe the "Consent required" switch can be on instead on the action
> itself, but the will still need to restrict if client is allowed or not
> to perform the action.
>

I can see your point for linking to external IdP.

However, for everything else the actions are requesting a user to enter
information before something happens. I.e. registering WebAuthn device,
update password, etc.. All require the user to first fill in the form.


>
> With regards to the flow, I suggest that KC will require full
> OIDC/OAuth2 flow. In other words, when KC redirects back to the client,
> the client will be required to send code-to-token request. And the
> action (EG. Keycloak user linked with Facebook) is done *after* the
> whole flow (including code-to-token flow) is finished. That should be
> sufficient to verify the client and at the same time, it will allow us
> to add some more things to tokens (EG. some facebook details) . Downside
> is, that it will be harder to implement though as the SPI will likely
> need another callback after code-to-token flow to "finish" the action...
>

I don't think I understand, because if you are proposing what I'm thinking
it sounds awkward. Can you list the flow?


>
> Last thing, I was thinking about using "scope" parameter to reference
> those actions instead of have proprietary "kc_action" thing. The we
> don't need any extensions of OIDC. It may simplify things like consents
> etc. Also client will be able to have something similar like we have in
> "Client Scopes" tab - the list of action, which he is allowed to
> initiate. But I am not sure about this last point and maybe it's better
> to keep things separated...
>

I'm not convinced using scope param makes sense. It just doesn't fit in my
mental model.


>
> Marek
>
>
>
>
> On 21/03/2019 14:07, Pedro Igor Silva wrote:
> > Sure, I'm not against the initial design/scope. Just tried to make
> comments
> > about other aspects that, to me, are related or how it can be leveraged
> to
> > also achieve other things.
> >
> > So, what Stian plans mentioned in one of his replies is fine for me.
> >
> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com>
> wrote:
> >
> >> Pedro,
> >>
> >> My only concern is getting this nailed down so we can move forward with
> >> the new account console.
> >>
> >> It sounds like Stian's proposal is simpler, but covers fewer use cases.
> >> Is that correct?
> >>
> >> Would it be practical to implement Stian's plan and then implement your
> >> proposal at a later date?
> >>
> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
> >>> In addition to everything you said.
> >>>
> >>> * It is not only about making changes to account, but updating tokens
> >> with
> >>> information from required actions, which not necessarily need to be
> >>> persisted.
> >>>
> >>> * For back-end applications, we could also associate these required
> >> actions
> >>> with scopes. If we could have a required action as "Re-authenticate" or
> >>> "Provide 2nd factor", that would also help with step-up authentication.
> >> As
> >>> an alternative to OIDC acr related parameters/claims. I don't think it
> >>> makes sense to bring to the client concerns that are really tied to the
> >>> scopes of a resource server. As I said, clients should ask for scopes
> and
> >>> Keycloak should do whatever is necessary to grant these (via consent,
> via
> >>> additional steps/actions). Consider what you mentioned at the end of
> your
> >>> design document at "Require Re-Authentication". Couldn't we leverage
> AIA
> >>> for step-up and ask the user for a more stronger credential ?
> >>>
> >>> * Claims gathering flow is simple. The Keycloak server would return the
> >>> endpoint to where the client should redirect the user. After obtaining
> >>> information from the user, Keycloak would issue a ticket (instead of
> >> code).
> >>> The endpoint returned by Keycloak would contain the action associated
> >> with
> >>> a resource. The endpoint could be the same as what you are using for
> AIA.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com>
> >>> wrote:
> >>>
> >>>> Pedro,
> >>>>
> >>>> I really don't understand what your points are and what you propose we
> >> do
> >>>> here.
> >>>>
> >>>> The use-case we're addressing is the following:
> >>>>
> >>>> As a user I would like to initiate an action associated with my
> account
> >>>> through a front-end application so that I can make changes to my
> >> account,
> >>>> for example to register a WebAuthn security key with my account.
> >>>>
> >>>> Further, we want an action to be implemented once and re-usable in
> >>>> login/registration flows as well as from applications managing user
> >>>> accounts, incuding our new account console. That means our new account
> >>>> console needs to be able to invoke an action in the login flow,
> >> otherwise
> >>>> we would have to implement actions as react/rest also.
> >>>>
> >>>> Now the solution I have proposed is simple. It allows an application
> to
> >>>> request an action being invoked after the user has authenticated.
> Think
> >> of
> >>>> it as a "required action" on-demand. It can be implemented with a few
> >> lines
> >>>> of code and easily tested. It is very easy to use as it just means
> >> adding
> >>>> an extra query param to the login flows, which makes it very easy to
> use
> >>>> both for confidential and non-confidential clients.
> >>>>
> >>>> It is not trying to cover claims gathering use-case from UMA. I see no
> >>>> connection to this and step-up authentication. These both already have
> >>>> clearly defined protocols. Neither can be used to address the above
> >>>> use-case.
> >>>>
> >>>> So please come with a concrete proposal as I have no clue what your
> >>>> objections are.
> >>>>
> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
> >> wrote:
> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <
> sthorger at redhat.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
> >> sthorger at redhat.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <psilva at redhat.com
> >
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
> >> sthorger at redhat.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <
> psilva at redhat.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
> >>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Is it this stuff you're thinking about:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>
> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
> >>>>>>>>>>>>   From that it does a get including the ticket as a query
> >> parameter.
> >>>>>>>>>>>> I don't like the idea of sending tickets as query params as
> >> they could be
> >>>>>>>>>>>> logged. For the application initiated action it would have to
> >> be an ID
> >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we
> >> have a way of
> >>>>>>>>>>>> creating a ticket that can only be used to initiate an action.
> >>>>>>>>>>>>
> >>>>>>>>>>> Why you need to send the id token if the client already got an
> id
> >>>>>>>>>>> token and, considering browser flow, there is a cookie that can
> >> be used by
> >>>>>>>>>>> Keycloak to identify the client/user ?
> >>>>>>>>>>>
> >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
> >>>>>>>>>>
> >>>>>>>>> But the identity cookie has the user session and from it we can
> >> check
> >>>>>>>>> whether or not the client initiating the action (client_id) has a
> >>>>>>>>> authenticated client session, no ?
> >>>>>>>>>
> >>>>>>>> That only proves that the client_id belongs to a client that has
> >>>>>>>> obtained a token. It doesn't authenticate the client in any way.
> >>>>>>>>
> >>>>>>>> Q- Why is authentication of the client required? IMO it is not
> >>>>>>>> required.
> >>>>>>>>
> >>>>>>> Sure, but the client obtained token and is authenticated, thus
> acting
> >>>>>>> on behalf of the user. If the client is already acting on behalf of
> >> a user,
> >>>>>>> we don't need to authenticate it.
> >>>>>>>
> >>>>>> That's not correct. All we know is that a client with the same
> >> client_id
> >>>>>> has obtained a token. Anyone can use the same client_id to initiate
> an
> >>>>>> action.
> >>>>>>
> >>>>>>
> >>>>>>>>>>>> Perhaps what we could do is:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. By default any application can initiate an action
> >>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of any
> >>>>>>>>>>>> sort, just a regular oauth flow
> >>>>>>>>>>>> 2. Later add support if demand to limit what applications can
> >>>>>>>>>>>> initiate actions
> >>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
> >>>>>>>>>>>> everyone then no need for a ticket
> >>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
> >>>>>>>>>>>> applications we would need some form of authentication.
> >>>>>>>>>>>>
> >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
> >>>>>>>>>>>>
> >>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA
> claim
> >>>>>>>>>>>> redirect does
> >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
> >> endpoint
> >>>>>>>>>>>> using an id token as bearer token
> >>>>>>>>>>>> c. Add a note into client session with a initiate action
> ticket
> >>>>>>>>>>>> for clients that can initiate actions and map this into the id
> >> token.
> >>>>>>>>>>> Not sure ...
> >>>>>>>>>>>
> >>>>>>>>>>> If you think about it, the part interested in obtaining the
> >> claims
> >>>>>>>>>>> after an action is completed is not the client but the audience
> >> of the
> >>>>>>>>>>> token, the resource server. In this case, the UMA approach
> seems
> >> more
> >>>>>>>>>>> appropriate because the resource server is in control about
> what
> >> actions
> >>>>>>>>>>> the client should initiate in order to fulfill the constraints
> >> imposed by
> >>>>>>>>>>> the resource server to access its protected resources. Where
> >> these
> >>>>>>>>>>> constraints could be a DOB in the token or a higher security
> >> level.
> >>>>>>>>>>> The app initiating actions in the server is not the goal, but
> the
> >>>>>>>>>>> tool to obtain additional claims from the server ...
> >>>>>>>>>>>
> >>>>>>>>>>> However, for some applications acting as both client and
> resource
> >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance
> >> and just
> >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
> >>>>>>>>>>>
> >>>>>>>>>> Perhaps there's a case for that, but that would be claims
> >> gathering,
> >>>>>>>>>> not application initiated actions.
> >>>>>>>>>>
> >>>>>>>>>> Application initiated actions are more a tool for folks to add
> >>>>>>>>>> actions for the user account into their own GUIs, and as such
> >> should be a
> >>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
> >> have any
> >>>>>>>>>> flows between app and service, but rather just allows the app to
> >> get the
> >>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
> >>>>>>>>>>
> >>>>>>>>> I think claims gathering and AIA are pretty much the same thing.
> >> Both
> >>>>>>>>> are querying the user for additional information. Despite if you
> >> are
> >>>>>>>>> initiating an action to request user's DOB or update a password,
> >> they are
> >>>>>>>>> steps that the user must perform in order to enrich its security
> >> context
> >>>>>>>>> and be able to continue using both client and resource server.
> >>>>>>>>>
> >>>>>>>>> The point I'm trying to make is that AIA can solve other problems
> >>>>>>>>> too. You would still solve the original problem from your design
> >> document
> >>>>>>>>> as defined in the motivation section. While you would also help
> >> with
> >>>>>>>>> step-up authentication and UMA claims gathering. Another point is
> >> related
> >>>>>>>>> to the party interested in the action. Is it the client or the
> >> resource
> >>>>>>>>> server (the API)?
> >>>>>>>>>
> >>>>>>>>> If the client (which honestly I don't see much use as most apps
> >> seem
> >>>>>>>>> to be a combination of front-end + back-end, where the
> >> functionality is
> >>>>>>>>> provided by the back-end and protected by a bearer token) then
> you
> >> may just
> >>>>>>>>> consider passing the "kc_action" parameter and have the action
> >> initiated.
> >>>>>>>>> If the resource server, you could associate the required actions
> >> with
> >>>>>>>>> the scopes. So when a client requests a specific scope, Keycloak
> >> will start
> >>>>>>>>> the action(s) and query the user for some information prior to
> >> issuing the
> >>>>>>>>> access token.
> >>>>>>>>>
> >>>>>>>>> Still, if the resource server, the resource server could respond
> to
> >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
> >> then the
> >>>>>>>>> client will just redirect the user to the location provided in
> the
> >> response
> >>>>>>>>> to initiate the actions.
> >>>>>>>>>
> >>>>>>>> I don't understand what your point is or what you are proposing
> >> here.
> >>>>>>> And I do understand your point of view. I just think that it can do
> >>>>>>> much more than address new account management console requirements.
> >>>>>>>
> >>>>>>> Based on your design document, I understand what you described in
> the
> >>>>>>> Motivation section. But again, instead of considering the "two
> >> things" that
> >>>>>>> originated the idea behind AIA, I think we can take the opportunity
> >> and do
> >>>>>>> much more. As they seem related to me. Especially after your DOB
> >> example.
> >>>>>> I don't see the additional use-cases you are mentioning as related
> at
> >>>>>> all.
> >>>>>>
> >>>>> How it is not related ? The audience of the information gathered
> during
> >>>>> the AIA does impact where the token with the information will be
> used.
> >> If I
> >>>>> need a DOB to access some page in my front-end, this is one thing.
> If I
> >>>>> need DOB to access some resource protected by a resource server it is
> >>>>> another thing. Both require tokens with different audiences, the
> former
> >>>>> will probably be an ID Token where the latter the access token.
> >>>>>
> >>>>> In OAuth2 the scopes represent the permissions to access protected
> >>>>> resources. Thus, it does make sense to have required actions that can
> >>>>> challenge a user when requesting scopes. Considering your DOB
> example,
> >> if
> >>>>> my client wants to access resource /api/age/check why you want the
> >> client
> >>>>> to request kc_action=dob if the scope "dob" is what he needs to
> access
> >> the
> >>>>> API ? Otherwise, you are making the client aware of things that are
> >> really
> >>>>> related to the resource server. It is OK the client ask for scope
> >> "age", it
> >>>>> is how OAuth2 authorization model works.
> >>>>>
> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
> >> client
> >>>>> really dumb about what it needs to access protected resources. With
> >> UMA,
> >>>>> the client will just receive a ticket and with that ticket it can
> >> perform
> >>>>> the necessary actions to make a successful authorization request to
> the
> >>>>> server.
> >>>>>
> >>>>>
> >>>>>> * Step-up authentication has already clear parameters in OIDC/OAuth
> to
> >>>>>> request high level of authentication. On the implementation side
> it's
> >> about
> >>>>>> invoking additional parts of the authentication flow, not to
> initiate
> >> an
> >>>>>> required action that has nothing to do with the authentication flow.
> >>>>>>
> >>>>> Can we consider a required action as a prompt for 2nd factor, for
> >>>>> instance ?
> >>>>>
> >>>>>
> >>>>>> * Claims gathering in UMA is about asking the user for additional
> >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
> >>>>>> gathering, but end of the day it's completely different. AIA will
> >> allow an
> >>>>>> app to invoke the action update_DOB, while claims gaterhing will
> >> allow the
> >>>>>> application to request the claim DOB.
> >>>>>>
> >>>>> Not sure, if the difference is due to updating a piece of info, both
> >>>>> flows request the user for the info. Is just a matter of updating or
> >> not
> >>>>> updating the info.
> >>>>>
> >>>>>
> >>>>>> I don't see what additional things we need to consider for something
> >>>>>> that is in the end very simple and can be implemented in a couple
> >> hours
> >>>>>> including tests if we don't try to make it more complicated.
> >>>>>>
> >>>>>>
> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
> >> sthorger at redhat.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
> >> psilva at redhat.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
> required?
> >>>>>>>>>>>>>>>>> The user will be prompted before making an action and
> it's
> >> an action they
> >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed
> to
> >> the client.
> >>>>>>>>>>>>>>>> The client is making the request and even though the user
> is
> >>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
> >> want to restrict
> >>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That is
> >> what I mean by
> >>>>>>>>>>>>>>>> some level of authorization.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You could even consider not authenticating the client at
> >> all,
> >>>>>>>>>>>>>>>> but still allow admins to enforce which clients should be
> >> allowed to
> >>>>>>>>>>>>>>>> initiate actions on the server.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
> >> initiate
> >>>>>>>>>>>>>>> actions will work without authenticating the client.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
> >>>>>>>>>>>>>> discussing. This is more a validation of the client making
> >> the request.
> >>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
> >> client_id and
> >>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
> >> doing browser
> >>>>>>>>>>>>>> authentication the cookie is already present) and possibly
> >> add some level
> >>>>>>>>>>>>>> of authorization to enforce which clients can perform
> actions
> >> (instead of
> >>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris
> are
> >> really
> >>>>>>>>>>>>>> important because you want to make sure the redirect uri is
> >> valid before
> >>>>>>>>>>>>>> redirecting the user.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
> >>>>>>>>>>>>> redirect_uris are already being checked. It's just a standard
> >> OAuth flow.
> >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
> >> clients
> >>>>>>>>>>>>> can initiate actions. If that's needed then we need something
> >> more
> >>>>>>>>>>>>> complicated that properly authenticates the client, as anyone
> >> could just
> >>>>>>>>>>>>> use the client_id and redirect_uri from a different
> >> application to get the
> >>>>>>>>>>>>> action initiated (although wouldn't then have the user
> >> redirected back to
> >>>>>>>>>>>>> the app of course).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints like
> >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
> >> user will be
> >>>>>>>>>>>>>>>>>> redirected back after the action completes). But still,
> >> we could also add
> >>>>>>>>>>>>>>>>>> some level authorization.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone can
> >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different
> >> client.
> >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
> >> happens
> >>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
> >> back to the client
> >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure
> that
> >> the client is
> >>>>>>>>>>>>>>>> known and that the user will be redirected back to a valid
> >> URI.
> >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new
> tokens.
> >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
> >> client wants that,
> >>>>>>>>>>>>>>> then they can request the user to enter a DOB, which would
> >> then result in
> >>>>>>>>>>>>>>> the DOB being available in the token.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This flow seems very closely related with the Claims
> Gathering
> >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there
> >> and see if it
> >>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Go for it ;)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
> >> where
> >>>>>>>>>>>>>>>>> the application can request a token to initate an action.
> >> So flow would be:
> >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token
> as
> >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
> >> return a single use
> >>>>>>>>>>>>>>>>> token.
> >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
> >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
> >> "?action-token=<action token>"
> >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
> >> that
> >>>>>>>>>>>>>>>>> would get the action token before redirecting the user.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients
> and
> >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions
> >> may be public
> >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol
> for
> >> this, but rather
> >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate
> the
> >>>>>>>>>>>>>>>>>>> client?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
> >>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
> >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple
> >> as leveraging authz
> >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
> >> Similar to what a KC
> >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
> >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on
> this
> >>>>>>>>>>>>>>>>>>>>> one.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of
> the
> >>>>>>>>>>>>>>>>>>>>> clients wanting to
> >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable
> about
> >>>>>>>>>>>>>>>>>>>>> not securing it and
> >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
> >>>>>>>>>>>>>>>>>>>>> anything, but welcome
> >>>>>>>>>>>>>>>>>>>>> others opinion on it.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
> >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
> >> action
> >>>>>>>>>>>>>>>>>>>>> (always
> >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined at
> >>>>>>>>>>>>>>>>>>>>> keycloak I see no
> >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
> mechanism.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
> >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are
> used
> >>>>>>>>>>>>>>>>>>>>> to prompt the user
> >>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account
> after
> >>>>>>>>>>>>>>>>>>>>> authenticating, but
> >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
> >>>>>>>>>>>>>>>>>>>>> validate email, etc.
> >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be manually
> >>>>>>>>>>>>>>>>>>>>> registered with the
> >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
> >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
> >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to
> verify
> >>>>>>>>>>>>>>>>>>>>> their email, but
> >>>>>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
> >>>>>>>>>>>>>>>>>>>>> account management
> >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
> >>>>>>>>>>>>>>>>>>>>> require verifying the
> >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
> >>>>>>>>>>>>>>>>>>>>> Application Initiated
> >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind the
> >>>>>>>>>>>>>>>>>>>>> scenes is just a
> >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
> >>>>>>>>>>>>>>>>>>>>> application and depending on
> >>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
> >>>>>>>>>>>>>>>>>>>>> (where the user can
> >>>>>>>>>>>>>>>>>>>>>> select
> >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
> >>>>>>>>>>>>>>>>>>>>> application).
> >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform any
> >>>>>>>>>>>>>>>>>>>>> updates to the users
> >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For
> example
> >>>>>>>>>>>>>>>>>>>>> an application
> >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
> >>>>>>>>>>>>>>>>>>>>> account to a social
> >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
> >>>>>>>>>>>>>>>>>>>>> link to the provider.
> >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate
> these I
> >>>>>>>>>>>>>>>>>>>>> would like to
> >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that applications
> >>>>>>>>>>>>>>>>>>>>> use to authenticate
> >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
> >>>>>>>>>>>>>>>>>>>>> application would redirect
> >>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
> kc_action=<action
> >>>>>>>>>>>>>>>>>>>>> alias> query
> >>>>>>>>>>>>>>>>>>>>>>> parameter.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming all
> >>>>>>>>>>>>>>>>>>>>> Application Initiated
> >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
> >>>>>>>>>>>>>>>>>>>>> add some mechanism in
> >>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
> >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
> >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
> >>>>>>>>>>>>>>>>>>>>> for applications.
> >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability
> for
> >>>>>>>>>>>>>>>>>>>>> an Application
> >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
> >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
> >>>>>>>>>>>>>>>>>>>>>> performing
> >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
> >>>>>>>>>>>>>>>>>>>>> require the user to enter
> >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should not
> >>>>>>>>>>>>>>>>>>>>> (as it simply sends
> >>>>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>>>>>>>>>>>>
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>>>>>>>>>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>>>>>>>>>>>>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Mar 22 07:49:13 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Mar 2019 12:49:13 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAd9Xfeu8ft2tbdtPGShSvU7KuO_so5cTsgZdP_3dGje9w@mail.gmail.com>
	<CAJgngAc_EiSZygf5UZY-Ksc-Hm77OgFF5Kop3aBLoro2mG8t+g@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
Message-ID: <CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>

To authenticate the client, why don't we just require id_token_hint to be
included?

We would require the ID token to be issued to the client trying to initiate
the action and also be associated with the current session.

I'd say we don't need to finely control what clients can do what at least
not for now. Client should have scope on the manage_account role and that's
enough for now.

On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I am sorry to join this so late.
>>
>> My concern is, that in the design, it was mentioned that consent will be
>> always required from the user. I understand that this simplifies the
>> flow as it's more secure and not need to authenticate the client.
>> However from the usability perspective, it doesn't look so nice to me.
>>
>> For example assume that in the application, the user just clicked on the
>> button "Link my account with Facebook" . Then after login with Facebook,
>> he will see another splash screen like "Application XY wants to link
>> your account with Facebook", which he needs to confirm. It may be
>> especially bad for usability in this case with linking social accounts,
>> as user may see one splash screen shown by Facebook "Application
>> keycloak wants to access your Facebook profile and email" and then
>> immediately another splash screen shown by Keycloak "Application Foo
>> wants to link your account with Facebook" .
>>
>> Maybe I am wrong, but my guess is, that our users will very quickly come
>> with requirement "Can I ommit to show the splash screen?" . It is bit
>> similar to the "Consent Required" switch, which I guess most people have
>> OFF for their clients. So IMO I would rather count with this from the
>> beginning and count with the fact, that we will need to ommit consent
>> screen and hence verify client.
>>
>> With regards to this, It seems that we may need also to specify if
>> client is:
>> - Allowed to initiate action
>> - Allowed to initate action with the consent required
>> - Allowed to initate action with no-consent required
>> Maybe the "Consent required" switch can be on instead on the action
>> itself, but the will still need to restrict if client is allowed or not
>> to perform the action.
>>
>
> I can see your point for linking to external IdP.
>
> However, for everything else the actions are requesting a user to enter
> information before something happens. I.e. registering WebAuthn device,
> update password, etc.. All require the user to first fill in the form.
>
>
>>
>> With regards to the flow, I suggest that KC will require full
>> OIDC/OAuth2 flow. In other words, when KC redirects back to the client,
>> the client will be required to send code-to-token request. And the
>> action (EG. Keycloak user linked with Facebook) is done *after* the
>> whole flow (including code-to-token flow) is finished. That should be
>> sufficient to verify the client and at the same time, it will allow us
>> to add some more things to tokens (EG. some facebook details) . Downside
>> is, that it will be harder to implement though as the SPI will likely
>> need another callback after code-to-token flow to "finish" the action...
>>
>
> I don't think I understand, because if you are proposing what I'm thinking
> it sounds awkward. Can you list the flow?
>
>
>>
>> Last thing, I was thinking about using "scope" parameter to reference
>> those actions instead of have proprietary "kc_action" thing. The we
>> don't need any extensions of OIDC. It may simplify things like consents
>> etc. Also client will be able to have something similar like we have in
>> "Client Scopes" tab - the list of action, which he is allowed to
>> initiate. But I am not sure about this last point and maybe it's better
>> to keep things separated...
>>
>
> I'm not convinced using scope param makes sense. It just doesn't fit in my
> mental model.
>
>
>>
>> Marek
>>
>>
>>
>>
>> On 21/03/2019 14:07, Pedro Igor Silva wrote:
>> > Sure, I'm not against the initial design/scope. Just tried to make
>> comments
>> > about other aspects that, to me, are related or how it can be leveraged
>> to
>> > also achieve other things.
>> >
>> > So, what Stian plans mentioned in one of his replies is fine for me.
>> >
>> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> >
>> >> Pedro,
>> >>
>> >> My only concern is getting this nailed down so we can move forward with
>> >> the new account console.
>> >>
>> >> It sounds like Stian's proposal is simpler, but covers fewer use cases.
>> >> Is that correct?
>> >>
>> >> Would it be practical to implement Stian's plan and then implement your
>> >> proposal at a later date?
>> >>
>> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>> >>> In addition to everything you said.
>> >>>
>> >>> * It is not only about making changes to account, but updating tokens
>> >> with
>> >>> information from required actions, which not necessarily need to be
>> >>> persisted.
>> >>>
>> >>> * For back-end applications, we could also associate these required
>> >> actions
>> >>> with scopes. If we could have a required action as "Re-authenticate"
>> or
>> >>> "Provide 2nd factor", that would also help with step-up
>> authentication.
>> >> As
>> >>> an alternative to OIDC acr related parameters/claims. I don't think it
>> >>> makes sense to bring to the client concerns that are really tied to
>> the
>> >>> scopes of a resource server. As I said, clients should ask for scopes
>> and
>> >>> Keycloak should do whatever is necessary to grant these (via consent,
>> via
>> >>> additional steps/actions). Consider what you mentioned at the end of
>> your
>> >>> design document at "Require Re-Authentication". Couldn't we leverage
>> AIA
>> >>> for step-up and ask the user for a more stronger credential ?
>> >>>
>> >>> * Claims gathering flow is simple. The Keycloak server would return
>> the
>> >>> endpoint to where the client should redirect the user. After obtaining
>> >>> information from the user, Keycloak would issue a ticket (instead of
>> >> code).
>> >>> The endpoint returned by Keycloak would contain the action associated
>> >> with
>> >>> a resource. The endpoint could be the same as what you are using for
>> AIA.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com
>> >
>> >>> wrote:
>> >>>
>> >>>> Pedro,
>> >>>>
>> >>>> I really don't understand what your points are and what you propose
>> we
>> >> do
>> >>>> here.
>> >>>>
>> >>>> The use-case we're addressing is the following:
>> >>>>
>> >>>> As a user I would like to initiate an action associated with my
>> account
>> >>>> through a front-end application so that I can make changes to my
>> >> account,
>> >>>> for example to register a WebAuthn security key with my account.
>> >>>>
>> >>>> Further, we want an action to be implemented once and re-usable in
>> >>>> login/registration flows as well as from applications managing user
>> >>>> accounts, incuding our new account console. That means our new
>> account
>> >>>> console needs to be able to invoke an action in the login flow,
>> >> otherwise
>> >>>> we would have to implement actions as react/rest also.
>> >>>>
>> >>>> Now the solution I have proposed is simple. It allows an application
>> to
>> >>>> request an action being invoked after the user has authenticated.
>> Think
>> >> of
>> >>>> it as a "required action" on-demand. It can be implemented with a few
>> >> lines
>> >>>> of code and easily tested. It is very easy to use as it just means
>> >> adding
>> >>>> an extra query param to the login flows, which makes it very easy to
>> use
>> >>>> both for confidential and non-confidential clients.
>> >>>>
>> >>>> It is not trying to cover claims gathering use-case from UMA. I see
>> no
>> >>>> connection to this and step-up authentication. These both already
>> have
>> >>>> clearly defined protocols. Neither can be used to address the above
>> >>>> use-case.
>> >>>>
>> >>>> So please come with a concrete proposal as I have no clue what your
>> >>>> objections are.
>> >>>>
>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <
>> sthorger at redhat.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <
>> psilva at redhat.com>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <
>> psilva at redhat.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>> >>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Is it this stuff you're thinking about:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>
>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>> >>>>>>>>>>>>   From that it does a get including the ticket as a query
>> >> parameter.
>> >>>>>>>>>>>> I don't like the idea of sending tickets as query params as
>> >> they could be
>> >>>>>>>>>>>> logged. For the application initiated action it would have to
>> >> be an ID
>> >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we
>> >> have a way of
>> >>>>>>>>>>>> creating a ticket that can only be used to initiate an
>> action.
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Why you need to send the id token if the client already got
>> an id
>> >>>>>>>>>>> token and, considering browser flow, there is a cookie that
>> can
>> >> be used by
>> >>>>>>>>>>> Keycloak to identify the client/user ?
>> >>>>>>>>>>>
>> >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>> >>>>>>>>>>
>> >>>>>>>>> But the identity cookie has the user session and from it we can
>> >> check
>> >>>>>>>>> whether or not the client initiating the action (client_id) has
>> a
>> >>>>>>>>> authenticated client session, no ?
>> >>>>>>>>>
>> >>>>>>>> That only proves that the client_id belongs to a client that has
>> >>>>>>>> obtained a token. It doesn't authenticate the client in any way.
>> >>>>>>>>
>> >>>>>>>> Q- Why is authentication of the client required? IMO it is not
>> >>>>>>>> required.
>> >>>>>>>>
>> >>>>>>> Sure, but the client obtained token and is authenticated, thus
>> acting
>> >>>>>>> on behalf of the user. If the client is already acting on behalf
>> of
>> >> a user,
>> >>>>>>> we don't need to authenticate it.
>> >>>>>>>
>> >>>>>> That's not correct. All we know is that a client with the same
>> >> client_id
>> >>>>>> has obtained a token. Anyone can use the same client_id to
>> initiate an
>> >>>>>> action.
>> >>>>>>
>> >>>>>>
>> >>>>>>>>>>>> Perhaps what we could do is:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> 1. By default any application can initiate an action
>> >>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of
>> any
>> >>>>>>>>>>>> sort, just a regular oauth flow
>> >>>>>>>>>>>> 2. Later add support if demand to limit what applications can
>> >>>>>>>>>>>> initiate actions
>> >>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>> >>>>>>>>>>>> everyone then no need for a ticket
>> >>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>> >>>>>>>>>>>> applications we would need some form of authentication.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA
>> claim
>> >>>>>>>>>>>> redirect does
>> >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>> >> endpoint
>> >>>>>>>>>>>> using an id token as bearer token
>> >>>>>>>>>>>> c. Add a note into client session with a initiate action
>> ticket
>> >>>>>>>>>>>> for clients that can initiate actions and map this into the
>> id
>> >> token.
>> >>>>>>>>>>> Not sure ...
>> >>>>>>>>>>>
>> >>>>>>>>>>> If you think about it, the part interested in obtaining the
>> >> claims
>> >>>>>>>>>>> after an action is completed is not the client but the
>> audience
>> >> of the
>> >>>>>>>>>>> token, the resource server. In this case, the UMA approach
>> seems
>> >> more
>> >>>>>>>>>>> appropriate because the resource server is in control about
>> what
>> >> actions
>> >>>>>>>>>>> the client should initiate in order to fulfill the constraints
>> >> imposed by
>> >>>>>>>>>>> the resource server to access its protected resources. Where
>> >> these
>> >>>>>>>>>>> constraints could be a DOB in the token or a higher security
>> >> level.
>> >>>>>>>>>>> The app initiating actions in the server is not the goal, but
>> the
>> >>>>>>>>>>> tool to obtain additional claims from the server ...
>> >>>>>>>>>>>
>> >>>>>>>>>>> However, for some applications acting as both client and
>> resource
>> >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance
>> >> and just
>> >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>> >>>>>>>>>>>
>> >>>>>>>>>> Perhaps there's a case for that, but that would be claims
>> >> gathering,
>> >>>>>>>>>> not application initiated actions.
>> >>>>>>>>>>
>> >>>>>>>>>> Application initiated actions are more a tool for folks to add
>> >>>>>>>>>> actions for the user account into their own GUIs, and as such
>> >> should be a
>> >>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
>> >> have any
>> >>>>>>>>>> flows between app and service, but rather just allows the app
>> to
>> >> get the
>> >>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>> >>>>>>>>>>
>> >>>>>>>>> I think claims gathering and AIA are pretty much the same thing.
>> >> Both
>> >>>>>>>>> are querying the user for additional information. Despite if you
>> >> are
>> >>>>>>>>> initiating an action to request user's DOB or update a password,
>> >> they are
>> >>>>>>>>> steps that the user must perform in order to enrich its security
>> >> context
>> >>>>>>>>> and be able to continue using both client and resource server.
>> >>>>>>>>>
>> >>>>>>>>> The point I'm trying to make is that AIA can solve other
>> problems
>> >>>>>>>>> too. You would still solve the original problem from your design
>> >> document
>> >>>>>>>>> as defined in the motivation section. While you would also help
>> >> with
>> >>>>>>>>> step-up authentication and UMA claims gathering. Another point
>> is
>> >> related
>> >>>>>>>>> to the party interested in the action. Is it the client or the
>> >> resource
>> >>>>>>>>> server (the API)?
>> >>>>>>>>>
>> >>>>>>>>> If the client (which honestly I don't see much use as most apps
>> >> seem
>> >>>>>>>>> to be a combination of front-end + back-end, where the
>> >> functionality is
>> >>>>>>>>> provided by the back-end and protected by a bearer token) then
>> you
>> >> may just
>> >>>>>>>>> consider passing the "kc_action" parameter and have the action
>> >> initiated.
>> >>>>>>>>> If the resource server, you could associate the required actions
>> >> with
>> >>>>>>>>> the scopes. So when a client requests a specific scope, Keycloak
>> >> will start
>> >>>>>>>>> the action(s) and query the user for some information prior to
>> >> issuing the
>> >>>>>>>>> access token.
>> >>>>>>>>>
>> >>>>>>>>> Still, if the resource server, the resource server could
>> respond to
>> >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
>> >> then the
>> >>>>>>>>> client will just redirect the user to the location provided in
>> the
>> >> response
>> >>>>>>>>> to initiate the actions.
>> >>>>>>>>>
>> >>>>>>>> I don't understand what your point is or what you are proposing
>> >> here.
>> >>>>>>> And I do understand your point of view. I just think that it can
>> do
>> >>>>>>> much more than address new account management console
>> requirements.
>> >>>>>>>
>> >>>>>>> Based on your design document, I understand what you described in
>> the
>> >>>>>>> Motivation section. But again, instead of considering the "two
>> >> things" that
>> >>>>>>> originated the idea behind AIA, I think we can take the
>> opportunity
>> >> and do
>> >>>>>>> much more. As they seem related to me. Especially after your DOB
>> >> example.
>> >>>>>> I don't see the additional use-cases you are mentioning as related
>> at
>> >>>>>> all.
>> >>>>>>
>> >>>>> How it is not related ? The audience of the information gathered
>> during
>> >>>>> the AIA does impact where the token with the information will be
>> used.
>> >> If I
>> >>>>> need a DOB to access some page in my front-end, this is one thing.
>> If I
>> >>>>> need DOB to access some resource protected by a resource server it
>> is
>> >>>>> another thing. Both require tokens with different audiences, the
>> former
>> >>>>> will probably be an ID Token where the latter the access token.
>> >>>>>
>> >>>>> In OAuth2 the scopes represent the permissions to access protected
>> >>>>> resources. Thus, it does make sense to have required actions that
>> can
>> >>>>> challenge a user when requesting scopes. Considering your DOB
>> example,
>> >> if
>> >>>>> my client wants to access resource /api/age/check why you want the
>> >> client
>> >>>>> to request kc_action=dob if the scope "dob" is what he needs to
>> access
>> >> the
>> >>>>> API ? Otherwise, you are making the client aware of things that are
>> >> really
>> >>>>> related to the resource server. It is OK the client ask for scope
>> >> "age", it
>> >>>>> is how OAuth2 authorization model works.
>> >>>>>
>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>> >> client
>> >>>>> really dumb about what it needs to access protected resources. With
>> >> UMA,
>> >>>>> the client will just receive a ticket and with that ticket it can
>> >> perform
>> >>>>> the necessary actions to make a successful authorization request to
>> the
>> >>>>> server.
>> >>>>>
>> >>>>>
>> >>>>>> * Step-up authentication has already clear parameters in
>> OIDC/OAuth to
>> >>>>>> request high level of authentication. On the implementation side
>> it's
>> >> about
>> >>>>>> invoking additional parts of the authentication flow, not to
>> initiate
>> >> an
>> >>>>>> required action that has nothing to do with the authentication
>> flow.
>> >>>>>>
>> >>>>> Can we consider a required action as a prompt for 2nd factor, for
>> >>>>> instance ?
>> >>>>>
>> >>>>>
>> >>>>>> * Claims gathering in UMA is about asking the user for additional
>> >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>> >>>>>> gathering, but end of the day it's completely different. AIA will
>> >> allow an
>> >>>>>> app to invoke the action update_DOB, while claims gaterhing will
>> >> allow the
>> >>>>>> application to request the claim DOB.
>> >>>>>>
>> >>>>> Not sure, if the difference is due to updating a piece of info, both
>> >>>>> flows request the user for the info. Is just a matter of updating or
>> >> not
>> >>>>> updating the info.
>> >>>>>
>> >>>>>
>> >>>>>> I don't see what additional things we need to consider for
>> something
>> >>>>>> that is in the end very simple and can be implemented in a couple
>> >> hours
>> >>>>>> including tests if we don't try to make it more complicated.
>> >>>>>>
>> >>>>>>
>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>> >> psilva at redhat.com>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
>> required?
>> >>>>>>>>>>>>>>>>> The user will be prompted before making an action and
>> it's
>> >> an action they
>> >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed
>> to
>> >> the client.
>> >>>>>>>>>>>>>>>> The client is making the request and even though the
>> user is
>> >>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
>> >> want to restrict
>> >>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That
>> is
>> >> what I mean by
>> >>>>>>>>>>>>>>>> some level of authorization.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> You could even consider not authenticating the client at
>> >> all,
>> >>>>>>>>>>>>>>>> but still allow admins to enforce which clients should be
>> >> allowed to
>> >>>>>>>>>>>>>>>> initiate actions on the server.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>> >> initiate
>> >>>>>>>>>>>>>>> actions will work without authenticating the client.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>> >>>>>>>>>>>>>> discussing. This is more a validation of the client making
>> >> the request.
>> >>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
>> >> client_id and
>> >>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
>> >> doing browser
>> >>>>>>>>>>>>>> authentication the cookie is already present) and possibly
>> >> add some level
>> >>>>>>>>>>>>>> of authorization to enforce which clients can perform
>> actions
>> >> (instead of
>> >>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris
>> are
>> >> really
>> >>>>>>>>>>>>>> important because you want to make sure the redirect uri is
>> >> valid before
>> >>>>>>>>>>>>>> redirecting the user.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>> >>>>>>>>>>>>> redirect_uris are already being checked. It's just a
>> standard
>> >> OAuth flow.
>> >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>> >> clients
>> >>>>>>>>>>>>> can initiate actions. If that's needed then we need
>> something
>> >> more
>> >>>>>>>>>>>>> complicated that properly authenticates the client, as
>> anyone
>> >> could just
>> >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>> >> application to get the
>> >>>>>>>>>>>>> action initiated (although wouldn't then have the user
>> >> redirected back to
>> >>>>>>>>>>>>> the app of course).
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints
>> like
>> >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
>> >> user will be
>> >>>>>>>>>>>>>>>>>> redirected back after the action completes). But still,
>> >> we could also add
>> >>>>>>>>>>>>>>>>>> some level authorization.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone
>> can
>> >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different
>> >> client.
>> >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>> >> happens
>> >>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
>> >> back to the client
>> >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure
>> that
>> >> the client is
>> >>>>>>>>>>>>>>>> known and that the user will be redirected back to a
>> valid
>> >> URI.
>> >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new
>> tokens.
>> >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
>> >> client wants that,
>> >>>>>>>>>>>>>>> then they can request the user to enter a DOB, which would
>> >> then result in
>> >>>>>>>>>>>>>>> the DOB being available in the token.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> This flow seems very closely related with the Claims
>> Gathering
>> >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there
>> >> and see if it
>> >>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> Go for it ;)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>> >> where
>> >>>>>>>>>>>>>>>>> the application can request a token to initate an
>> action.
>> >> So flow would be:
>> >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token
>> as
>> >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>> >> return a single use
>> >>>>>>>>>>>>>>>>> token.
>> >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>> >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>> >> "?action-token=<action token>"
>> >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
>> >> that
>> >>>>>>>>>>>>>>>>> would get the action token before redirecting the user.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients
>> and
>> >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions
>> >> may be public
>> >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol
>> for
>> >> this, but rather
>> >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate
>> the
>> >>>>>>>>>>>>>>>>>>> client?
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>> >>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>> >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple
>> >> as leveraging authz
>> >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>> >> Similar to what a KC
>> >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on
>> this
>> >>>>>>>>>>>>>>>>>>>>> one.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of
>> the
>> >>>>>>>>>>>>>>>>>>>>> clients wanting to
>> >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable
>> about
>> >>>>>>>>>>>>>>>>>>>>> not securing it and
>> >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>> >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>> >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>> >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
>> >> action
>> >>>>>>>>>>>>>>>>>>>>> (always
>> >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined
>> at
>> >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>> >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
>> mechanism.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>> >>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are
>> used
>> >>>>>>>>>>>>>>>>>>>>> to prompt the user
>> >>>>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account
>> after
>> >>>>>>>>>>>>>>>>>>>>> authenticating, but
>> >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>> >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>> >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be
>> manually
>> >>>>>>>>>>>>>>>>>>>>> registered with the
>> >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>> >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>> >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to
>> verify
>> >>>>>>>>>>>>>>>>>>>>> their email, but
>> >>>>>>>>>>>>>>>>>>>>>> only
>> >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>> >>>>>>>>>>>>>>>>>>>>> account management
>> >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>> >>>>>>>>>>>>>>>>>>>>> require verifying the
>> >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>> >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind
>> the
>> >>>>>>>>>>>>>>>>>>>>> scenes is just a
>> >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>> >>>>>>>>>>>>>>>>>>>>> application and depending on
>> >>>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>> >>>>>>>>>>>>>>>>>>>>> (where the user can
>> >>>>>>>>>>>>>>>>>>>>>> select
>> >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>> >>>>>>>>>>>>>>>>>>>>> application).
>> >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform
>> any
>> >>>>>>>>>>>>>>>>>>>>> updates to the users
>> >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For
>> example
>> >>>>>>>>>>>>>>>>>>>>> an application
>> >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
>> >>>>>>>>>>>>>>>>>>>>> account to a social
>> >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
>> >>>>>>>>>>>>>>>>>>>>> link to the provider.
>> >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate
>> these I
>> >>>>>>>>>>>>>>>>>>>>> would like to
>> >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>> applications
>> >>>>>>>>>>>>>>>>>>>>> use to authenticate
>> >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>> >>>>>>>>>>>>>>>>>>>>> application would redirect
>> >>>>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>> kc_action=<action
>> >>>>>>>>>>>>>>>>>>>>> alias> query
>> >>>>>>>>>>>>>>>>>>>>>>> parameter.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming
>> all
>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>> >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
>> >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>> >>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>> >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>> >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
>> >>>>>>>>>>>>>>>>>>>>> for applications.
>> >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability
>> for
>> >>>>>>>>>>>>>>>>>>>>> an Application
>> >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>> >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>> >>>>>>>>>>>>>>>>>>>>>> performing
>> >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>> >>>>>>>>>>>>>>>>>>>>> require the user to enter
>> >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should
>> not
>> >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>> >>>>>>>>>>>>>>>>>>>>>> an
>> >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>> >>>>>>>>>>>>>>>>>>>>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>>>>>>>>>>>>>>>>>>
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From mposolda at redhat.com  Fri Mar 22 10:12:29 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Mar 2019 15:12:29 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
Message-ID: <f26ca599-2d4f-ebab-daea-b900f0317b01@redhat.com>

On 22/03/2019 12:42, Stian Thorgersen wrote:
>
>
> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I am sorry to join this so late.
>
>     My concern is, that in the design, it was mentioned that consent
>     will be
>     always required from the user. I understand that this simplifies the
>     flow as it's more secure and not need to authenticate the client.
>     However from the usability perspective, it doesn't look so nice to me.
>
>     For example assume that in the application, the user just clicked
>     on the
>     button "Link my account with Facebook" . Then after login with
>     Facebook,
>     he will see another splash screen like "Application XY wants to link
>     your account with Facebook", which he needs to confirm. It may be
>     especially bad for usability in this case with linking social
>     accounts,
>     as user may see one splash screen shown by Facebook "Application
>     keycloak wants to access your Facebook profile and email" and then
>     immediately another splash screen shown by Keycloak "Application Foo
>     wants to link your account with Facebook" .
>
>     Maybe I am wrong, but my guess is, that our users will very
>     quickly come
>     with requirement "Can I ommit to show the splash screen?" . It is bit
>     similar to the "Consent Required" switch, which I guess most
>     people have
>     OFF for their clients. So IMO I would rather count with this from the
>     beginning and count with the fact, that we will need to ommit consent
>     screen and hence verify client.
>
>     With regards to this, It seems that we may need also to specify if
>     client is:
>     - Allowed to initiate action
>     - Allowed to initate action with the consent required
>     - Allowed to initate action with no-consent required
>     Maybe the "Consent required" switch can be on instead on the action
>     itself, but the will still need to restrict if client is allowed
>     or not
>     to perform the action.
>
>
> I can see your point for linking to external IdP.
>
> However, for everything else the actions are requesting a user to 
> enter information before something happens. I.e. registering WebAuthn 
> device, update password, etc.. All require the user to first fill in 
> the form.
I see. But if we can think about at least of one "type" of the action, 
which may not show any special page, there are probably others :)
>
>     With regards to the flow, I suggest that KC will require full
>     OIDC/OAuth2 flow. In other words, when KC redirects back to the
>     client,
>     the client will be required to send code-to-token request. And the
>     action (EG. Keycloak user linked with Facebook) is done *after* the
>     whole flow (including code-to-token flow) is finished. That should be
>     sufficient to verify the client and at the same time, it will
>     allow us
>     to add some more things to tokens (EG. some facebook details) .
>     Downside
>     is, that it will be harder to implement though as the SPI will likely
>     need another callback after code-to-token flow to "finish" the
>     action...
>
>
> I don't think I understand, because if you are proposing what I'm 
> thinking it sounds awkward. Can you list the flow?

It is pretty much OIDC flow. So:

- The initial request with "kc_action=link-facebook" is sent to OIDC 
authentication endpoint
- KC (re-)authenticates user and do all the UI actions required for the 
requested action
- Before the model is updated (EG. 
userModel.addFederationLink("facebook") called), there is redirection to 
client with code+state etc
- Client needs to send code-to-token request.
- KC will need to verify code (already done), finally finish the model 
(EG. call "user.addFederationLink" or "user.setEmailVerified(true)" ). 
That's where I think the SPI callback will be needed. Finally 
re-generate tokens and verify back to the application.
- Client receives updated tokens with all the new state (EG. 
"email_verified" is set to true, user's birthday claim retrieved from 
facebook is in the token etc.)

This has some good advantages like the:

- Client is verified. In case of confidential clients, there is proper 
client authentication. For public clients, there is at least redirection 
back to the client application and exchanging for tokens, which is still 
bit safer than just update model on server (EG. 
userModel.addFederationLink) and redirect to client after. However for 
public clients, people will more likely want to show the splash screen 
"Application XY wants to link your account"

- Tokens are updated at the end of the flow. This is important for many 
applications though as in many cases, people will likely trigger actions 
under some conditions. For example in the application will do something 
like:

if (!idToken.isEmailVerified()) {
 ??? redirectToVerifyEmailAction();

}

So without updated tokens, you will have infinite loop or the need to 
re-trigger to OIDC flow manually again to have tokens refreshed with new 
claims

>
>     Last thing, I was thinking about using "scope" parameter to reference
>     those actions instead of have proprietary "kc_action" thing. The we
>     don't need any extensions of OIDC. It may simplify things like
>     consents
>     etc. Also client will be able to have something similar like we
>     have in
>     "Client Scopes" tab - the list of action, which he is allowed to
>     initiate. But I am not sure about this last point and maybe it's
>     better
>     to keep things separated...
>
>
> I'm not convinced using scope param makes sense. It just doesn't fit 
> in my mental model.

I see. I am also not convinced so much about scope param... Just some 
quick idea :)

Marek

>
>     Marek
>
>
>
>
>     On 21/03/2019 14:07, Pedro Igor Silva wrote:
>     > Sure, I'm not against the initial design/scope. Just tried to
>     make comments
>     > about other aspects that, to me, are related or how it can be
>     leveraged to
>     > also achieve other things.
>     >
>     > So, what Stian plans mentioned in one of his replies is fine for me.
>     >
>     > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
>     <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>     >
>     >> Pedro,
>     >>
>     >> My only concern is getting this nailed down so we can move
>     forward with
>     >> the new account console.
>     >>
>     >> It sounds like Stian's proposal is simpler, but covers fewer
>     use cases.
>     >> Is that correct?
>     >>
>     >> Would it be practical to implement Stian's plan and then
>     implement your
>     >> proposal at a later date?
>     >>
>     >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>     >>> In addition to everything you said.
>     >>>
>     >>> * It is not only about making changes to account, but updating
>     tokens
>     >> with
>     >>> information from required actions, which not necessarily need
>     to be
>     >>> persisted.
>     >>>
>     >>> * For back-end applications, we could also associate these
>     required
>     >> actions
>     >>> with scopes. If we could have a required action as
>     "Re-authenticate" or
>     >>> "Provide 2nd factor", that would also help with step-up
>     authentication.
>     >> As
>     >>> an alternative to OIDC acr related parameters/claims. I don't
>     think it
>     >>> makes sense to bring to the client concerns that are really
>     tied to the
>     >>> scopes of a resource server. As I said, clients should ask for
>     scopes and
>     >>> Keycloak should do whatever is necessary to grant these (via
>     consent, via
>     >>> additional steps/actions). Consider what you mentioned at the
>     end of your
>     >>> design document at "Require Re-Authentication". Couldn't we
>     leverage AIA
>     >>> for step-up and ask the user for a more stronger credential ?
>     >>>
>     >>> * Claims gathering flow is simple. The Keycloak server would
>     return the
>     >>> endpoint to where the client should redirect the user. After
>     obtaining
>     >>> information from the user, Keycloak would issue a ticket
>     (instead of
>     >> code).
>     >>> The endpoint returned by Keycloak would contain the action
>     associated
>     >> with
>     >>> a resource. The endpoint could be the same as what you are
>     using for AIA.
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>> wrote:
>     >>>
>     >>>> Pedro,
>     >>>>
>     >>>> I really don't understand what your points are and what you
>     propose we
>     >> do
>     >>>> here.
>     >>>>
>     >>>> The use-case we're addressing is the following:
>     >>>>
>     >>>> As a user I would like to initiate an action associated with
>     my account
>     >>>> through a front-end application so that I can make changes to my
>     >> account,
>     >>>> for example to register a WebAuthn security key with my account.
>     >>>>
>     >>>> Further, we want an action to be implemented once and
>     re-usable in
>     >>>> login/registration flows as well as from applications
>     managing user
>     >>>> accounts, incuding our new account console. That means our
>     new account
>     >>>> console needs to be able to invoke an action in the login flow,
>     >> otherwise
>     >>>> we would have to implement actions as react/rest also.
>     >>>>
>     >>>> Now the solution I have proposed is simple. It allows an
>     application to
>     >>>> request an action being invoked after the user has
>     authenticated. Think
>     >> of
>     >>>> it as a "required action" on-demand. It can be implemented
>     with a few
>     >> lines
>     >>>> of code and easily tested. It is very easy to use as it just
>     means
>     >> adding
>     >>>> an extra query param to the login flows, which makes it very
>     easy to use
>     >>>> both for confidential and non-confidential clients.
>     >>>>
>     >>>> It is not trying to cover claims gathering use-case from UMA.
>     I see no
>     >>>> connection to this and step-up authentication. These both
>     already have
>     >>>> clearly defined protocols. Neither can be used to address the
>     above
>     >>>> use-case.
>     >>>>
>     >>>> So please come with a concrete proposal as I have no clue
>     what your
>     >>>> objections are.
>     >>>>
>     >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
>     <psilva at redhat.com <mailto:psilva at redhat.com>>
>     >> wrote:
>     >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>>>> wrote:
>     >>>>>
>     >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva
>     <psilva at redhat.com <mailto:psilva at redhat.com>>
>     >>>>>> wrote:
>     >>>>>>
>     >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>     >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>>>>>> wrote:
>     >>>>>>>
>     >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
>     <psilva at redhat.com <mailto:psilva at redhat.com>>
>     >>>>>>>> wrote:
>     >>>>>>>>
>     >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>     >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>>>>>>>> wrote:
>     >>>>>>>>>
>     >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva
>     <psilva at redhat.com <mailto:psilva at redhat.com>>
>     >>>>>>>>>> wrote:
>     >>>>>>>>>>
>     >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>     >>>>>>>>>>> sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>     >>>>>>>>>>>
>     >>>>>>>>>>>> Is it this stuff you're thinking about:
>     >>>>>>>>>>>>
>     >>>>>>>>>>>>
>     >>
>     https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>     >>>>>>>>>>>>? ?From that it does a get including the ticket as a query
>     >> parameter.
>     >>>>>>>>>>>> I don't like the idea of sending tickets as query
>     params as
>     >> they could be
>     >>>>>>>>>>>> logged. For the application initiated action it would
>     have to
>     >> be an ID
>     >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before
>     perhaps we
>     >> have a way of
>     >>>>>>>>>>>> creating a ticket that can only be used to initiate
>     an action.
>     >>>>>>>>>>>>
>     >>>>>>>>>>> Why you need to send the id token if the client
>     already got an id
>     >>>>>>>>>>> token and, considering browser flow, there is a cookie
>     that can
>     >> be used by
>     >>>>>>>>>>> Keycloak to identify the client/user ?
>     >>>>>>>>>>>
>     >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>     >>>>>>>>>>
>     >>>>>>>>> But the identity cookie has the user session and from it
>     we can
>     >> check
>     >>>>>>>>> whether or not the client initiating the action
>     (client_id) has a
>     >>>>>>>>> authenticated client session, no ?
>     >>>>>>>>>
>     >>>>>>>> That only proves that the client_id belongs to a client
>     that has
>     >>>>>>>> obtained a token. It doesn't authenticate the client in
>     any way.
>     >>>>>>>>
>     >>>>>>>> Q- Why is authentication of the client required? IMO it
>     is not
>     >>>>>>>> required.
>     >>>>>>>>
>     >>>>>>> Sure, but the client obtained token and is authenticated,
>     thus acting
>     >>>>>>> on behalf of the user. If the client is already acting on
>     behalf of
>     >> a user,
>     >>>>>>> we don't need to authenticate it.
>     >>>>>>>
>     >>>>>> That's not correct. All we know is that a client with the same
>     >> client_id
>     >>>>>> has obtained a token. Anyone can use the same client_id to
>     initiate an
>     >>>>>> action.
>     >>>>>>
>     >>>>>>
>     >>>>>>>>>>>> Perhaps what we could do is:
>     >>>>>>>>>>>>
>     >>>>>>>>>>>> 1. By default any application can initiate an action
>     >>>>>>>>>>>> 1.1. To initiate an action there's no need for a
>     ticket of any
>     >>>>>>>>>>>> sort, just a regular oauth flow
>     >>>>>>>>>>>> 2. Later add support if demand to limit what
>     applications can
>     >>>>>>>>>>>> initiate actions
>     >>>>>>>>>>>> 2.1 Same as before if the action being initiated is
>     open for
>     >>>>>>>>>>>> everyone then no need for a ticket
>     >>>>>>>>>>>> 2.2 If the action being initiated is only permitted
>     by some
>     >>>>>>>>>>>> applications we would need some form of authentication.
>     >>>>>>>>>>>>
>     >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>     >>>>>>>>>>>>
>     >>>>>>>>>>>> a. Just include id_token as a ticket query param
>     like? UMA claim
>     >>>>>>>>>>>> redirect does
>     >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>     >> endpoint
>     >>>>>>>>>>>> using an id token as bearer token
>     >>>>>>>>>>>> c. Add a note into client session with a initiate
>     action ticket
>     >>>>>>>>>>>> for clients that can initiate actions and map this
>     into the id
>     >> token.
>     >>>>>>>>>>> Not sure ...
>     >>>>>>>>>>>
>     >>>>>>>>>>> If you think about it, the part interested in
>     obtaining the
>     >> claims
>     >>>>>>>>>>> after an action is completed is not the client but the
>     audience
>     >> of the
>     >>>>>>>>>>> token, the resource server. In this case, the UMA
>     approach seems
>     >> more
>     >>>>>>>>>>> appropriate because the resource server is in control
>     about what
>     >> actions
>     >>>>>>>>>>> the client should initiate in order to fulfill the
>     constraints
>     >> imposed by
>     >>>>>>>>>>> the resource server to access its protected resources.
>     Where
>     >> these
>     >>>>>>>>>>> constraints could be a DOB in the token or a higher
>     security
>     >> level.
>     >>>>>>>>>>> The app initiating actions in the server is not the
>     goal, but the
>     >>>>>>>>>>> tool to obtain additional claims from the server ...
>     >>>>>>>>>>>
>     >>>>>>>>>>> However, for some applications acting as both client
>     and resource
>     >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the
>     ticket dance
>     >> and just
>     >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>     >>>>>>>>>>>
>     >>>>>>>>>> Perhaps there's a case for that, but that would be claims
>     >> gathering,
>     >>>>>>>>>> not application initiated actions.
>     >>>>>>>>>>
>     >>>>>>>>>> Application initiated actions are more a tool for folks
>     to add
>     >>>>>>>>>> actions for the user account into their own GUIs, and
>     as such
>     >> should be a
>     >>>>>>>>>> simple protocol. OAuth incremental scopes for example
>     doesn't
>     >> have any
>     >>>>>>>>>> flows between app and service, but rather just allows
>     the app to
>     >> get the
>     >>>>>>>>>> scopes it out of bounds knows it needs for specific
>     actions.
>     >>>>>>>>>>
>     >>>>>>>>> I think claims gathering and AIA are pretty much the
>     same thing.
>     >> Both
>     >>>>>>>>> are querying the user for additional information.
>     Despite if you
>     >> are
>     >>>>>>>>> initiating an action to request user's DOB or update a
>     password,
>     >> they are
>     >>>>>>>>> steps that the user must perform in order to enrich its
>     security
>     >> context
>     >>>>>>>>> and be able to continue using both client and resource
>     server.
>     >>>>>>>>>
>     >>>>>>>>> The point I'm trying to make is that AIA can solve other
>     problems
>     >>>>>>>>> too. You would still solve the original problem from
>     your design
>     >> document
>     >>>>>>>>> as defined in the motivation section. While you would
>     also help
>     >> with
>     >>>>>>>>> step-up authentication and UMA claims gathering. Another
>     point is
>     >> related
>     >>>>>>>>> to the party interested in the action. Is it the client
>     or the
>     >> resource
>     >>>>>>>>> server (the API)?
>     >>>>>>>>>
>     >>>>>>>>> If the client (which honestly I don't see much use as
>     most apps
>     >> seem
>     >>>>>>>>> to be a combination of front-end + back-end, where the
>     >> functionality is
>     >>>>>>>>> provided by the back-end and protected by a bearer
>     token) then you
>     >> may just
>     >>>>>>>>> consider passing the "kc_action" parameter and have the
>     action
>     >> initiated.
>     >>>>>>>>> If the resource server, you could associate the required
>     actions
>     >> with
>     >>>>>>>>> the scopes. So when a client requests a specific scope,
>     Keycloak
>     >> will start
>     >>>>>>>>> the action(s) and query the user for some information
>     prior to
>     >> issuing the
>     >>>>>>>>> access token.
>     >>>>>>>>>
>     >>>>>>>>> Still, if the resource server, the resource server could
>     respond to
>     >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more
>     info,
>     >> then the
>     >>>>>>>>> client will just redirect the user to the location
>     provided in the
>     >> response
>     >>>>>>>>> to initiate the actions.
>     >>>>>>>>>
>     >>>>>>>> I don't understand what your point is or what you are
>     proposing
>     >> here.
>     >>>>>>> And I do understand your point of view. I just think that
>     it can do
>     >>>>>>> much more than address new account management console
>     requirements.
>     >>>>>>>
>     >>>>>>> Based on your design document, I understand what you
>     described in the
>     >>>>>>> Motivation section. But again, instead of considering the "two
>     >> things" that
>     >>>>>>> originated the idea behind AIA, I think we can take the
>     opportunity
>     >> and do
>     >>>>>>> much more. As they seem related to me. Especially after
>     your DOB
>     >> example.
>     >>>>>> I don't see the additional use-cases you are mentioning as
>     related at
>     >>>>>> all.
>     >>>>>>
>     >>>>> How it is not related ? The audience of the information
>     gathered during
>     >>>>> the AIA does impact where the token with the information
>     will be used.
>     >> If I
>     >>>>> need a DOB to access some page in my front-end, this is one
>     thing. If I
>     >>>>> need DOB to access some resource protected by a resource
>     server it is
>     >>>>> another thing. Both require tokens with different audiences,
>     the former
>     >>>>> will probably be an ID Token where the latter the access token.
>     >>>>>
>     >>>>> In OAuth2 the scopes represent the permissions to access
>     protected
>     >>>>> resources. Thus, it does make sense to have required actions
>     that can
>     >>>>> challenge a user when requesting scopes. Considering your
>     DOB example,
>     >> if
>     >>>>> my client wants to access resource /api/age/check why you
>     want the
>     >> client
>     >>>>> to request kc_action=dob if the scope "dob" is what he needs
>     to access
>     >> the
>     >>>>> API ? Otherwise, you are making the client aware of things
>     that are
>     >> really
>     >>>>> related to the resource server. It is OK the client ask for
>     scope
>     >> "age", it
>     >>>>> is how OAuth2 authorization model works.
>     >>>>>
>     >>>>> UMA leverages OAuth2 in a way that the permission ticket
>     makes the
>     >> client
>     >>>>> really dumb about what it needs to access protected
>     resources. With
>     >> UMA,
>     >>>>> the client will just receive a ticket and with that ticket
>     it can
>     >> perform
>     >>>>> the necessary actions to make a successful authorization
>     request to the
>     >>>>> server.
>     >>>>>
>     >>>>>
>     >>>>>> * Step-up authentication has already clear parameters in
>     OIDC/OAuth to
>     >>>>>> request high level of authentication. On the implementation
>     side it's
>     >> about
>     >>>>>> invoking additional parts of the authentication flow, not
>     to initiate
>     >> an
>     >>>>>> required action that has nothing to do with the
>     authentication flow.
>     >>>>>>
>     >>>>> Can we consider a required action as a prompt for 2nd
>     factor, for
>     >>>>> instance ?
>     >>>>>
>     >>>>>
>     >>>>>> * Claims gathering in UMA is about asking the user for
>     additional
>     >>>>>> claims. AIA can be used as a poor-mans workaround to lack
>     of claims
>     >>>>>> gathering, but end of the day it's completely different.
>     AIA will
>     >> allow an
>     >>>>>> app to invoke the action update_DOB, while claims gaterhing
>     will
>     >> allow the
>     >>>>>> application to request the claim DOB.
>     >>>>>>
>     >>>>> Not sure, if the difference is due to updating a piece of
>     info, both
>     >>>>> flows request the user for the info. Is just a matter of
>     updating or
>     >> not
>     >>>>> updating the info.
>     >>>>>
>     >>>>>
>     >>>>>> I don't see what additional things we need to consider for
>     something
>     >>>>>> that is in the end very simple and can be implemented in a
>     couple
>     >> hours
>     >>>>>> including tests if we don't try to make it more complicated.
>     >>>>>>
>     >>>>>>
>     >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>     >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>>>>>>>>>>> wrote:
>     >>>>>>>>>>>>
>     >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>     >> psilva at redhat.com <mailto:psilva at redhat.com>>
>     >>>>>>>>>>>>> wrote:
>     >>>>>>>>>>>>>
>     >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>     >>>>>>>>>>>>>> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     wrote:
>     >>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>     >>>>>>>>>>>>>>> psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>     >>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>     >>>>>>>>>>>>>>>> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     wrote:
>     >>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
>     required?
>     >>>>>>>>>>>>>>>>> The user will be prompted before making an
>     action and it's
>     >> an action they
>     >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>     visible/exposed to
>     >> the client.
>     >>>>>>>>>>>>>>>> The client is making the request and even though
>     the user is
>     >>>>>>>>>>>>>>>> at the Keycloak server to perform the action,
>     admins may
>     >> want to restrict
>     >>>>>>>>>>>>>>>> which clients are allowed to perform such
>     actions. That is
>     >> what I mean by
>     >>>>>>>>>>>>>>>> some level of authorization.
>     >>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>> You could even consider not authenticating the
>     client at
>     >> all,
>     >>>>>>>>>>>>>>>> but still allow admins to enforce which clients
>     should be
>     >> allowed to
>     >>>>>>>>>>>>>>>> initiate actions on the server.
>     >>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>     >> initiate
>     >>>>>>>>>>>>>>> actions will work without authenticating the client.
>     >>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what
>     we are
>     >>>>>>>>>>>>>> discussing. This is more a validation of the client
>     making
>     >> the request.
>     >>>>>>>>>>>>>> Considering that, I'm saying that you could just
>     rely on
>     >> client_id and
>     >>>>>>>>>>>>>> redirect uris (the client is already authenticated
>     and if
>     >> doing browser
>     >>>>>>>>>>>>>> authentication the cookie is already present) and
>     possibly
>     >> add some level
>     >>>>>>>>>>>>>> of authorization to enforce which clients can
>     perform actions
>     >> (instead of
>     >>>>>>>>>>>>>> just relying on the authenticated session).
>     Redirect uris are
>     >> really
>     >>>>>>>>>>>>>> important because you want to make sure the
>     redirect uri is
>     >> valid before
>     >>>>>>>>>>>>>> redirecting the user.
>     >>>>>>>>>>>>>>
>     >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>     >>>>>>>>>>>>> redirect_uris are already being checked. It's just a
>     standard
>     >> OAuth flow.
>     >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>     >> clients
>     >>>>>>>>>>>>> can initiate actions. If that's needed then we need
>     something
>     >> more
>     >>>>>>>>>>>>> complicated that properly authenticates the client,
>     as anyone
>     >> could just
>     >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>     >> application to get the
>     >>>>>>>>>>>>> action initiated (although wouldn't then have the user
>     >> redirected back to
>     >>>>>>>>>>>>> the app of course).
>     >>>>>>>>>>>>>
>     >>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>     >>>>>>>>>>>>>>>>> psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>> One way is to follow authorization code
>     constraints like
>     >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri
>     (assuming the
>     >> user will be
>     >>>>>>>>>>>>>>>>>> redirected back after the action completes).
>     But still,
>     >> we could also add
>     >>>>>>>>>>>>>>>>>> some level authorization.
>     >>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as
>     anyone can
>     >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a
>     different
>     >> client.
>     >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then
>     what
>     >> happens
>     >>>>>>>>>>>>>>>> after the user performs an action. Is he/her
>     redirected
>     >> back to the client
>     >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make
>     sure that
>     >> the client is
>     >>>>>>>>>>>>>>>> known and that the user will be redirected back
>     to a valid
>     >> URI.
>     >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get
>     new tokens.
>     >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile
>     and the
>     >> client wants that,
>     >>>>>>>>>>>>>>> then they can request the user to enter a DOB,
>     which would
>     >> then result in
>     >>>>>>>>>>>>>>> the DOB being available in the token.
>     >>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>> This flow seems very closely related with the
>     Claims Gathering
>     >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what
>     is there
>     >> and see if it
>     >>>>>>>>>>>>>> can help to solve this problem of app initiated
>     actions.
>     >>>>>>>>>>>>>>
>     >>>>>>>>>>>>> Go for it ;)
>     >>>>>>>>>>>>>
>     >>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an
>     endpoint
>     >> where
>     >>>>>>>>>>>>>>>>> the application can request a token to initate
>     an action.
>     >> So flow would be:
>     >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with
>     ID Token as
>     >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>     >> return a single use
>     >>>>>>>>>>>>>>>>> token.
>     >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as
>     before, but
>     >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>     >> "?action-token=<action token>"
>     >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId)
>     function
>     >> that
>     >>>>>>>>>>>>>>>>> would get the action token before redirecting
>     the user.
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>     >>>>>>>>>>>>>>>>>> sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>     >>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate
>     clients and
>     >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate
>     actions
>     >> may be public
>     >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new
>     protocol for
>     >> this, but rather
>     >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>     >>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>> So with those constraints how would you
>     authenticate the
>     >>>>>>>>>>>>>>>>>>> client?
>     >>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>     >>>>>>>>>>>>>>>>>>> psilva at redhat.com <mailto:psilva at redhat.com>>
>     wrote:
>     >>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of
>     authorization for
>     >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be
>     as simple
>     >> as leveraging authz
>     >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>     >> Similar to what a KC
>     >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>     >>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>     >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>     >>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the
>     list on this
>     >>>>>>>>>>>>>>>>>>>>> one.
>     >>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>> Especially around not having any
>     authentication of the
>     >>>>>>>>>>>>>>>>>>>>> clients wanting to
>     >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable
>     comfortable about
>     >>>>>>>>>>>>>>>>>>>>> not securing it and
>     >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before
>     doing
>     >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>     >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>     >>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>     >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com
>     <mailto:pskopek at redhat.com>> wrote:
>     >>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application
>     initiated
>     >> action
>     >>>>>>>>>>>>>>>>>>>>> (always
>     >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are
>     predefined at
>     >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>     >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
>     mechanism.
>     >>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian
>     Thorgersen <
>     >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>     <mailto:sthorger at redhat.com>>
>     >>>>>>>>>>>>>>>>>>>>>> wrote:
>     >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions
>     that are used
>     >>>>>>>>>>>>>>>>>>>>> to prompt the user
>     >>>>>>>>>>>>>>>>>>>>>> to
>     >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their
>     account after
>     >>>>>>>>>>>>>>>>>>>>> authenticating, but
>     >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update
>     profile,
>     >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>     >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be
>     manually
>     >>>>>>>>>>>>>>>>>>>>> registered with the
>     >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>     >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>     >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all
>     users to verify
>     >>>>>>>>>>>>>>>>>>>>> their email, but
>     >>>>>>>>>>>>>>>>>>>>>> only
>     >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions
>     from the
>     >>>>>>>>>>>>>>>>>>>>> account management
>     >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address
>     should
>     >>>>>>>>>>>>>>>>>>>>> require verifying the
>     >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to
>     introduce
>     >>>>>>>>>>>>>>>>>>>>> Application Initiated
>     >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action
>     behind the
>     >>>>>>>>>>>>>>>>>>>>> scenes is just a
>     >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>     >>>>>>>>>>>>>>>>>>>>> application and depending on
>     >>>>>>>>>>>>>>>>>>>>>> the
>     >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to
>     complete
>     >>>>>>>>>>>>>>>>>>>>> (where the user can
>     >>>>>>>>>>>>>>>>>>>>>> select
>     >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>     >>>>>>>>>>>>>>>>>>>>> application).
>     >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should
>     perform any
>     >>>>>>>>>>>>>>>>>>>>> updates to the users
>     >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first.
>     For example
>     >>>>>>>>>>>>>>>>>>>>> an application
>     >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an
>     existing
>     >>>>>>>>>>>>>>>>>>>>> account to a social
>     >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they
>     want to
>     >>>>>>>>>>>>>>>>>>>>> link to the provider.
>     >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to
>     integrate these I
>     >>>>>>>>>>>>>>>>>>>>> would like to
>     >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>     applications
>     >>>>>>>>>>>>>>>>>>>>> use to authenticate
>     >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>     >>>>>>>>>>>>>>>>>>>>> application would redirect
>     >>>>>>>>>>>>>>>>>>>>>> to
>     >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>     kc_action=<action
>     >>>>>>>>>>>>>>>>>>>>> alias> query
>     >>>>>>>>>>>>>>>>>>>>>>> parameter.
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is.
>     Assuming all
>     >>>>>>>>>>>>>>>>>>>>> Application Initiated
>     >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we
>     need to
>     >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>     >>>>>>>>>>>>>>>>>>>>>>> place to restrict what
>     clients/applications are
>     >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>     >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it
>     harder to use
>     >>>>>>>>>>>>>>>>>>>>> for applications.
>     >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the
>     ability for
>     >>>>>>>>>>>>>>>>>>>>> an Application
>     >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>     >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>     >>>>>>>>>>>>>>>>>>>>>> performing
>     >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>     >>>>>>>>>>>>>>>>>>>>> require the user to enter
>     >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email
>     should not
>     >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>     >>>>>>>>>>>>>>>>>>>>>> an
>     >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>     >>>>>>>>>>>>>>>>>>>>>>>
>     _______________________________________________
>     >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>     >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>>>>>>>>>>>>>>>>>>>>>>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>>>>>>>>>>>>>>>>>>>> _______________________________________________
>     >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>     >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>>>>>>>>>>>>>>>>>>>>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>>>>>>>>>>>>>>>>>>>>
>     >>> _______________________________________________
>     >>> keycloak-dev mailing list
>     >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>
>     >> _______________________________________________
>     >> keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <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
>


From mposolda at redhat.com  Fri Mar 22 10:20:34 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Mar 2019 15:20:34 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
Message-ID: <ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>

On 22/03/2019 12:49, Stian Thorgersen wrote:
> To authenticate the client, why don't we just require?id_token_hint to 
> be included?
>
> We would require the ID token to be issued to the client trying to 
> initiate the action and also be associated with the current session.
>
> I'd say we don't need to finely control what clients can do what at 
> least not for now. Client should have scope on the manage_account role 
> and that's enough for now.

This assumes that client is authenticated before action is triggered. 
Don't we want also a possibility to trigger this "Application Initiated 
Actions" for cases when user is not yet authenticated? For example if I 
have web application, which will be something like "Web Email client", I 
want to ensure that user always has email verified before he is 
redirected to my application as authenticated. So I may want to trigger 
OIDC flow with "kc_action" even before user is authenticated.

Will be also nice for the "Terms and Conditions" actions as the "Terms 
and Conditions" pages are often client specific, so our current approach 
with generic "Terms and Conditions" action is likely not so nice and 
requires that many application implements some equivalent of 
app-specific "Terms and Conditions" page on their side rather than rely 
on Keycloak. But with those "Application Initiated Actions" we can 
improve on here.

Marek

>
> On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>
>
>     On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         I am sorry to join this so late.
>
>         My concern is, that in the design, it was mentioned that
>         consent will be
>         always required from the user. I understand that this
>         simplifies the
>         flow as it's more secure and not need to authenticate the client.
>         However from the usability perspective, it doesn't look so
>         nice to me.
>
>         For example assume that in the application, the user just
>         clicked on the
>         button "Link my account with Facebook" . Then after login with
>         Facebook,
>         he will see another splash screen like "Application XY wants
>         to link
>         your account with Facebook", which he needs to confirm. It may be
>         especially bad for usability in this case with linking social
>         accounts,
>         as user may see one splash screen shown by Facebook "Application
>         keycloak wants to access your Facebook profile and email" and
>         then
>         immediately another splash screen shown by Keycloak
>         "Application Foo
>         wants to link your account with Facebook" .
>
>         Maybe I am wrong, but my guess is, that our users will very
>         quickly come
>         with requirement "Can I ommit to show the splash screen?" . It
>         is bit
>         similar to the "Consent Required" switch, which I guess most
>         people have
>         OFF for their clients. So IMO I would rather count with this
>         from the
>         beginning and count with the fact, that we will need to ommit
>         consent
>         screen and hence verify client.
>
>         With regards to this, It seems that we may need also to
>         specify if
>         client is:
>         - Allowed to initiate action
>         - Allowed to initate action with the consent required
>         - Allowed to initate action with no-consent required
>         Maybe the "Consent required" switch can be on instead on the
>         action
>         itself, but the will still need to restrict if client is
>         allowed or not
>         to perform the action.
>
>
>     I can see your point for linking to external IdP.
>
>     However, for everything else the actions are requesting a user to
>     enter information before something happens. I.e. registering
>     WebAuthn device, update password, etc.. All require the user to
>     first fill in the form.
>
>
>         With regards to the flow, I suggest that KC will require full
>         OIDC/OAuth2 flow. In other words, when KC redirects back to
>         the client,
>         the client will be required to send code-to-token request. And
>         the
>         action (EG. Keycloak user linked with Facebook) is done
>         *after* the
>         whole flow (including code-to-token flow) is finished. That
>         should be
>         sufficient to verify the client and at the same time, it will
>         allow us
>         to add some more things to tokens (EG. some facebook details)
>         . Downside
>         is, that it will be harder to implement though as the SPI will
>         likely
>         need another callback after code-to-token flow to "finish" the
>         action...
>
>
>     I don't think I understand, because if you are proposing what I'm
>     thinking it sounds awkward. Can you list the flow?
>
>
>         Last thing, I was thinking about using "scope" parameter to
>         reference
>         those actions instead of have proprietary "kc_action" thing.
>         The we
>         don't need any extensions of OIDC. It may simplify things like
>         consents
>         etc. Also client will be able to have something similar like
>         we have in
>         "Client Scopes" tab - the list of action, which he is allowed to
>         initiate. But I am not sure about this last point and maybe
>         it's better
>         to keep things separated...
>
>
>     I'm not convinced using scope param makes sense. It just doesn't
>     fit in my mental model.
>
>
>         Marek
>
>
>
>
>         On 21/03/2019 14:07, Pedro Igor Silva wrote:
>         > Sure, I'm not against the initial design/scope. Just tried
>         to make comments
>         > about other aspects that, to me, are related or how it can
>         be leveraged to
>         > also achieve other things.
>         >
>         > So, what Stian plans mentioned in one of his replies is fine
>         for me.
>         >
>         > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>         >
>         >> Pedro,
>         >>
>         >> My only concern is getting this nailed down so we can move
>         forward with
>         >> the new account console.
>         >>
>         >> It sounds like Stian's proposal is simpler, but covers
>         fewer use cases.
>         >> Is that correct?
>         >>
>         >> Would it be practical to implement Stian's plan and then
>         implement your
>         >> proposal at a later date?
>         >>
>         >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>         >>> In addition to everything you said.
>         >>>
>         >>> * It is not only about making changes to account, but
>         updating tokens
>         >> with
>         >>> information from required actions, which not necessarily
>         need to be
>         >>> persisted.
>         >>>
>         >>> * For back-end applications, we could also associate these
>         required
>         >> actions
>         >>> with scopes. If we could have a required action as
>         "Re-authenticate" or
>         >>> "Provide 2nd factor", that would also help with step-up
>         authentication.
>         >> As
>         >>> an alternative to OIDC acr related parameters/claims. I
>         don't think it
>         >>> makes sense to bring to the client concerns that are
>         really tied to the
>         >>> scopes of a resource server. As I said, clients should ask
>         for scopes and
>         >>> Keycloak should do whatever is necessary to grant these
>         (via consent, via
>         >>> additional steps/actions). Consider what you mentioned at
>         the end of your
>         >>> design document at "Require Re-Authentication". Couldn't
>         we leverage AIA
>         >>> for step-up and ask the user for a more stronger credential ?
>         >>>
>         >>> * Claims gathering flow is simple. The Keycloak server
>         would return the
>         >>> endpoint to where the client should redirect the user.
>         After obtaining
>         >>> information from the user, Keycloak would issue a ticket
>         (instead of
>         >> code).
>         >>> The endpoint returned by Keycloak would contain the action
>         associated
>         >> with
>         >>> a resource. The endpoint could be the same as what you are
>         using for AIA.
>         >>>
>         >>>
>         >>>
>         >>>
>         >>>
>         >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         >>> wrote:
>         >>>
>         >>>> Pedro,
>         >>>>
>         >>>> I really don't understand what your points are and what
>         you propose we
>         >> do
>         >>>> here.
>         >>>>
>         >>>> The use-case we're addressing is the following:
>         >>>>
>         >>>> As a user I would like to initiate an action associated
>         with my account
>         >>>> through a front-end application so that I can make
>         changes to my
>         >> account,
>         >>>> for example to register a WebAuthn security key with my
>         account.
>         >>>>
>         >>>> Further, we want an action to be implemented once and
>         re-usable in
>         >>>> login/registration flows as well as from applications
>         managing user
>         >>>> accounts, incuding our new account console. That means
>         our new account
>         >>>> console needs to be able to invoke an action in the login
>         flow,
>         >> otherwise
>         >>>> we would have to implement actions as react/rest also.
>         >>>>
>         >>>> Now the solution I have proposed is simple. It allows an
>         application to
>         >>>> request an action being invoked after the user has
>         authenticated. Think
>         >> of
>         >>>> it as a "required action" on-demand. It can be
>         implemented with a few
>         >> lines
>         >>>> of code and easily tested. It is very easy to use as it
>         just means
>         >> adding
>         >>>> an extra query param to the login flows, which makes it
>         very easy to use
>         >>>> both for confidential and non-confidential clients.
>         >>>>
>         >>>> It is not trying to cover claims gathering use-case from
>         UMA. I see no
>         >>>> connection to this and step-up authentication. These both
>         already have
>         >>>> clearly defined protocols. Neither can be used to address
>         the above
>         >>>> use-case.
>         >>>>
>         >>>> So please come with a concrete proposal as I have no clue
>         what your
>         >>>> objections are.
>         >>>>
>         >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>         >> wrote:
>         >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen
>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         >>>>> wrote:
>         >>>>>
>         >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva
>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>         >>>>>> wrote:
>         >>>>>>
>         >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         >>>>>>> wrote:
>         >>>>>>>
>         >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>         >>>>>>>> wrote:
>         >>>>>>>>
>         >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         >>>>>>>>> wrote:
>         >>>>>>>>>
>         >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva
>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>         >>>>>>>>>> wrote:
>         >>>>>>>>>>
>         >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>         >>>>>>>>>>> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         wrote:
>         >>>>>>>>>>>
>         >>>>>>>>>>>> Is it this stuff you're thinking about:
>         >>>>>>>>>>>>
>         >>>>>>>>>>>>
>         >>
>         https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>         >>>>>>>>>>>>? ?From that it does a get including the ticket as
>         a query
>         >> parameter.
>         >>>>>>>>>>>> I don't like the idea of sending tickets as query
>         params as
>         >> they could be
>         >>>>>>>>>>>> logged. For the application initiated action it
>         would have to
>         >> be an ID
>         >>>>>>>>>>>> token sent as the ticket. Or as I mentioned
>         before perhaps we
>         >> have a way of
>         >>>>>>>>>>>> creating a ticket that can only be used to
>         initiate an action.
>         >>>>>>>>>>>>
>         >>>>>>>>>>> Why you need to send the id token if the client
>         already got an id
>         >>>>>>>>>>> token and, considering browser flow, there is a
>         cookie that can
>         >> be used by
>         >>>>>>>>>>> Keycloak to identify the client/user ?
>         >>>>>>>>>>>
>         >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>         >>>>>>>>>>
>         >>>>>>>>> But the identity cookie has the user session and
>         from it we can
>         >> check
>         >>>>>>>>> whether or not the client initiating the action
>         (client_id) has a
>         >>>>>>>>> authenticated client session, no ?
>         >>>>>>>>>
>         >>>>>>>> That only proves that the client_id belongs to a
>         client that has
>         >>>>>>>> obtained a token. It doesn't authenticate the client
>         in any way.
>         >>>>>>>>
>         >>>>>>>> Q- Why is authentication of the client required? IMO
>         it is not
>         >>>>>>>> required.
>         >>>>>>>>
>         >>>>>>> Sure, but the client obtained token and is
>         authenticated, thus acting
>         >>>>>>> on behalf of the user. If the client is already acting
>         on behalf of
>         >> a user,
>         >>>>>>> we don't need to authenticate it.
>         >>>>>>>
>         >>>>>> That's not correct. All we know is that a client with
>         the same
>         >> client_id
>         >>>>>> has obtained a token. Anyone can use the same client_id
>         to initiate an
>         >>>>>> action.
>         >>>>>>
>         >>>>>>
>         >>>>>>>>>>>> Perhaps what we could do is:
>         >>>>>>>>>>>>
>         >>>>>>>>>>>> 1. By default any application can initiate an action
>         >>>>>>>>>>>> 1.1. To initiate an action there's no need for a
>         ticket of any
>         >>>>>>>>>>>> sort, just a regular oauth flow
>         >>>>>>>>>>>> 2. Later add support if demand to limit what
>         applications can
>         >>>>>>>>>>>> initiate actions
>         >>>>>>>>>>>> 2.1 Same as before if the action being initiated
>         is open for
>         >>>>>>>>>>>> everyone then no need for a ticket
>         >>>>>>>>>>>> 2.2 If the action being initiated is only
>         permitted by some
>         >>>>>>>>>>>> applications we would need some form of
>         authentication.
>         >>>>>>>>>>>>
>         >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>         >>>>>>>>>>>>
>         >>>>>>>>>>>> a. Just include id_token as a ticket query param
>         like? UMA claim
>         >>>>>>>>>>>> redirect does
>         >>>>>>>>>>>> b. Add support to obtain an initiate action
>         ticket from a
>         >> endpoint
>         >>>>>>>>>>>> using an id token as bearer token
>         >>>>>>>>>>>> c. Add a note into client session with a initiate
>         action ticket
>         >>>>>>>>>>>> for clients that can initiate actions and map
>         this into the id
>         >> token.
>         >>>>>>>>>>> Not sure ...
>         >>>>>>>>>>>
>         >>>>>>>>>>> If you think about it, the part interested in
>         obtaining the
>         >> claims
>         >>>>>>>>>>> after an action is completed is not the client but
>         the audience
>         >> of the
>         >>>>>>>>>>> token, the resource server. In this case, the UMA
>         approach seems
>         >> more
>         >>>>>>>>>>> appropriate because the resource server is in
>         control about what
>         >> actions
>         >>>>>>>>>>> the client should initiate in order to fulfill the
>         constraints
>         >> imposed by
>         >>>>>>>>>>> the resource server to access its protected
>         resources. Where
>         >> these
>         >>>>>>>>>>> constraints could be a DOB in the token or a
>         higher security
>         >> level.
>         >>>>>>>>>>> The app initiating actions in the server is not
>         the goal, but the
>         >>>>>>>>>>> tool to obtain additional claims from the server ...
>         >>>>>>>>>>>
>         >>>>>>>>>>> However, for some applications acting as both
>         client and resource
>         >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the
>         ticket dance
>         >> and just
>         >>>>>>>>>>> redirect the user to the server as you pointed out
>         in 1.
>         >>>>>>>>>>>
>         >>>>>>>>>> Perhaps there's a case for that, but that would be
>         claims
>         >> gathering,
>         >>>>>>>>>> not application initiated actions.
>         >>>>>>>>>>
>         >>>>>>>>>> Application initiated actions are more a tool for
>         folks to add
>         >>>>>>>>>> actions for the user account into their own GUIs,
>         and as such
>         >> should be a
>         >>>>>>>>>> simple protocol. OAuth incremental scopes for
>         example doesn't
>         >> have any
>         >>>>>>>>>> flows between app and service, but rather just
>         allows the app to
>         >> get the
>         >>>>>>>>>> scopes it out of bounds knows it needs for specific
>         actions.
>         >>>>>>>>>>
>         >>>>>>>>> I think claims gathering and AIA are pretty much the
>         same thing.
>         >> Both
>         >>>>>>>>> are querying the user for additional information.
>         Despite if you
>         >> are
>         >>>>>>>>> initiating an action to request user's DOB or update
>         a password,
>         >> they are
>         >>>>>>>>> steps that the user must perform in order to enrich
>         its security
>         >> context
>         >>>>>>>>> and be able to continue using both client and
>         resource server.
>         >>>>>>>>>
>         >>>>>>>>> The point I'm trying to make is that AIA can solve
>         other problems
>         >>>>>>>>> too. You would still solve the original problem from
>         your design
>         >> document
>         >>>>>>>>> as defined in the motivation section. While you
>         would also help
>         >> with
>         >>>>>>>>> step-up authentication and UMA claims gathering.
>         Another point is
>         >> related
>         >>>>>>>>> to the party interested in the action. Is it the
>         client or the
>         >> resource
>         >>>>>>>>> server (the API)?
>         >>>>>>>>>
>         >>>>>>>>> If the client (which honestly I don't see much use
>         as most apps
>         >> seem
>         >>>>>>>>> to be a combination of front-end + back-end, where the
>         >> functionality is
>         >>>>>>>>> provided by the back-end and protected by a bearer
>         token) then you
>         >> may just
>         >>>>>>>>> consider passing the "kc_action" parameter and have
>         the action
>         >> initiated.
>         >>>>>>>>> If the resource server, you could associate the
>         required actions
>         >> with
>         >>>>>>>>> the scopes. So when a client requests a specific
>         scope, Keycloak
>         >> will start
>         >>>>>>>>> the action(s) and query the user for some
>         information prior to
>         >> issuing the
>         >>>>>>>>> access token.
>         >>>>>>>>>
>         >>>>>>>>> Still, if the resource server, the resource server
>         could respond to
>         >>>>>>>>> the client (e.g: UMA flow) indicating that it needs
>         more info,
>         >> then the
>         >>>>>>>>> client will just redirect the user to the location
>         provided in the
>         >> response
>         >>>>>>>>> to initiate the actions.
>         >>>>>>>>>
>         >>>>>>>> I don't understand what your point is or what you are
>         proposing
>         >> here.
>         >>>>>>> And I do understand your point of view. I just think
>         that it can do
>         >>>>>>> much more than address new account management console
>         requirements.
>         >>>>>>>
>         >>>>>>> Based on your design document, I understand what you
>         described in the
>         >>>>>>> Motivation section. But again, instead of considering
>         the "two
>         >> things" that
>         >>>>>>> originated the idea behind AIA, I think we can take
>         the opportunity
>         >> and do
>         >>>>>>> much more. As they seem related to me. Especially
>         after your DOB
>         >> example.
>         >>>>>> I don't see the additional use-cases you are mentioning
>         as related at
>         >>>>>> all.
>         >>>>>>
>         >>>>> How it is not related ? The audience of the information
>         gathered during
>         >>>>> the AIA does impact where the token with the information
>         will be used.
>         >> If I
>         >>>>> need a DOB to access some page in my front-end, this is
>         one thing. If I
>         >>>>> need DOB to access some resource protected by a resource
>         server it is
>         >>>>> another thing. Both require tokens with different
>         audiences, the former
>         >>>>> will probably be an ID Token where the latter the access
>         token.
>         >>>>>
>         >>>>> In OAuth2 the scopes represent the permissions to access
>         protected
>         >>>>> resources. Thus, it does make sense to have required
>         actions that can
>         >>>>> challenge a user when requesting scopes. Considering
>         your DOB example,
>         >> if
>         >>>>> my client wants to access resource /api/age/check why
>         you want the
>         >> client
>         >>>>> to request kc_action=dob if the scope "dob" is what he
>         needs to access
>         >> the
>         >>>>> API ? Otherwise, you are making the client aware of
>         things that are
>         >> really
>         >>>>> related to the resource server. It is OK the client ask
>         for scope
>         >> "age", it
>         >>>>> is how OAuth2 authorization model works.
>         >>>>>
>         >>>>> UMA leverages OAuth2 in a way that the permission ticket
>         makes the
>         >> client
>         >>>>> really dumb about what it needs to access protected
>         resources. With
>         >> UMA,
>         >>>>> the client will just receive a ticket and with that
>         ticket it can
>         >> perform
>         >>>>> the necessary actions to make a successful authorization
>         request to the
>         >>>>> server.
>         >>>>>
>         >>>>>
>         >>>>>> * Step-up authentication has already clear parameters
>         in OIDC/OAuth to
>         >>>>>> request high level of authentication. On the
>         implementation side it's
>         >> about
>         >>>>>> invoking additional parts of the authentication flow,
>         not to initiate
>         >> an
>         >>>>>> required action that has nothing to do with the
>         authentication flow.
>         >>>>>>
>         >>>>> Can we consider a required action as a prompt for 2nd
>         factor, for
>         >>>>> instance ?
>         >>>>>
>         >>>>>
>         >>>>>> * Claims gathering in UMA is about asking the user for
>         additional
>         >>>>>> claims. AIA can be used as a poor-mans workaround to
>         lack of claims
>         >>>>>> gathering, but end of the day it's completely
>         different. AIA will
>         >> allow an
>         >>>>>> app to invoke the action update_DOB, while claims
>         gaterhing will
>         >> allow the
>         >>>>>> application to request the claim DOB.
>         >>>>>>
>         >>>>> Not sure, if the difference is due to updating a piece
>         of info, both
>         >>>>> flows request the user for the info. Is just a matter of
>         updating or
>         >> not
>         >>>>> updating the info.
>         >>>>>
>         >>>>>
>         >>>>>> I don't see what additional things we need to consider
>         for something
>         >>>>>> that is in the end very simple and can be implemented
>         in a couple
>         >> hours
>         >>>>>> including tests if we don't try to make it more
>         complicated.
>         >>>>>>
>         >>>>>>
>         >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         >>>>>>>>>>>> wrote:
>         >>>>>>>>>>>>
>         >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>         >> psilva at redhat.com <mailto:psilva at redhat.com>>
>         >>>>>>>>>>>>> wrote:
>         >>>>>>>>>>>>>
>         >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>         >>>>>>>>>>>>>> sthorger at redhat.com
>         <mailto:sthorger at redhat.com>> wrote:
>         >>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>         >>>>>>>>>>>>>>> psilva at redhat.com <mailto:psilva at redhat.com>>
>         wrote:
>         >>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>         >>>>>>>>>>>>>>>> sthorger at redhat.com
>         <mailto:sthorger at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>> Why do you think
>         authentication/authorization is required?
>         >>>>>>>>>>>>>>>>> The user will be prompted before making an
>         action and it's
>         >> an action they
>         >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>         visible/exposed to
>         >> the client.
>         >>>>>>>>>>>>>>>> The client is making the request and even
>         though the user is
>         >>>>>>>>>>>>>>>> at the Keycloak server to perform the action,
>         admins may
>         >> want to restrict
>         >>>>>>>>>>>>>>>> which clients are allowed to perform such
>         actions. That is
>         >> what I mean by
>         >>>>>>>>>>>>>>>> some level of authorization.
>         >>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>> You could even consider not authenticating
>         the client at
>         >> all,
>         >>>>>>>>>>>>>>>> but still allow admins to enforce which
>         clients should be
>         >> allowed to
>         >>>>>>>>>>>>>>>> initiate actions on the server.
>         >>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>> I can't see how enforcing which clients is
>         allowed to
>         >> initiate
>         >>>>>>>>>>>>>>> actions will work without authenticating the
>         client.
>         >>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>> Maybe the word authenticate seems too much to
>         what we are
>         >>>>>>>>>>>>>> discussing. This is more a validation of the
>         client making
>         >> the request.
>         >>>>>>>>>>>>>> Considering that, I'm saying that you could
>         just rely on
>         >> client_id and
>         >>>>>>>>>>>>>> redirect uris (the client is already
>         authenticated and if
>         >> doing browser
>         >>>>>>>>>>>>>> authentication the cookie is already present)
>         and possibly
>         >> add some level
>         >>>>>>>>>>>>>> of authorization to enforce which clients can
>         perform actions
>         >> (instead of
>         >>>>>>>>>>>>>> just relying on the authenticated session).
>         Redirect uris are
>         >> really
>         >>>>>>>>>>>>>> important because you want to make sure the
>         redirect uri is
>         >> valid before
>         >>>>>>>>>>>>>> redirecting the user.
>         >>>>>>>>>>>>>>
>         >>>>>>>>>>>>> The plan is to use the auth endpoint, so
>         client_id and
>         >>>>>>>>>>>>> redirect_uris are already being checked. It's
>         just a standard
>         >> OAuth flow.
>         >>>>>>>>>>>>> IMO that's fine as long as there's no need to
>         limit what
>         >> clients
>         >>>>>>>>>>>>> can initiate actions. If that's needed then we
>         need something
>         >> more
>         >>>>>>>>>>>>> complicated that properly authenticates the
>         client, as anyone
>         >> could just
>         >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>         >> application to get the
>         >>>>>>>>>>>>> action initiated (although wouldn't then have
>         the user
>         >> redirected back to
>         >>>>>>>>>>>>> the app of course).
>         >>>>>>>>>>>>>
>         >>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>         >>>>>>>>>>>>>>>>> psilva at redhat.com
>         <mailto:psilva at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>> One way is to follow authorization code
>         constraints like
>         >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri
>         (assuming the
>         >> user will be
>         >>>>>>>>>>>>>>>>>> redirected back after the action
>         completes). But still,
>         >> we could also add
>         >>>>>>>>>>>>>>>>>> some level authorization.
>         >>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>> authorization code constraints doesn't work
>         as anyone can
>         >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from
>         a different
>         >> client.
>         >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask
>         then what
>         >> happens
>         >>>>>>>>>>>>>>>> after the user performs an action. Is he/her
>         redirected
>         >> back to the client
>         >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to
>         make sure that
>         >> the client is
>         >>>>>>>>>>>>>>>> known and that the user will be redirected
>         back to a valid
>         >> URI.
>         >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would
>         get new tokens.
>         >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the
>         profile and the
>         >> client wants that,
>         >>>>>>>>>>>>>>> then they can request the user to enter a DOB,
>         which would
>         >> then result in
>         >>>>>>>>>>>>>>> the DOB being available in the token.
>         >>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>> This flow seems very closely related with the
>         Claims Gathering
>         >>>>>>>>>>>>>> Flow from UMA specs. We could probably review
>         what is there
>         >> and see if it
>         >>>>>>>>>>>>>> can help to solve this problem of app initiated
>         actions.
>         >>>>>>>>>>>>>>
>         >>>>>>>>>>>>> Go for it ;)
>         >>>>>>>>>>>>>
>         >>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>> Only viable option I can think of is to add
>         an endpoint
>         >> where
>         >>>>>>>>>>>>>>>>> the application can request a token to
>         initate an action.
>         >> So flow would be:
>         >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> }
>         with ID Token as
>         >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint.
>         This would
>         >> return a single use
>         >>>>>>>>>>>>>>>>> token.
>         >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as
>         before, but
>         >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>         >> "?action-token=<action token>"
>         >>>>>>>>>>>>>>>>> In the JS adapter we can add a
>         action(actionId) function
>         >> that
>         >>>>>>>>>>>>>>>>> would get the action token before
>         redirecting the user.
>         >>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>> Not sure what you mean about level
>         authorization.
>         >>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian
>         Thorgersen <
>         >>>>>>>>>>>>>>>>>> sthorger at redhat.com
>         <mailto:sthorger at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>> The issue is more around how to
>         authenticate clients and
>         >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to
>         initiate actions
>         >> may be public
>         >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a
>         new protocol for
>         >> this, but rather
>         >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>         >>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>> So with those constraints how would you
>         authenticate the
>         >>>>>>>>>>>>>>>>>>> client?
>         >>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor
>         Silva <
>         >>>>>>>>>>>>>>>>>>> psilva at redhat.com
>         <mailto:psilva at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of
>         authorization for
>         >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could
>         be as simple
>         >> as leveraging authz
>         >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of
>         clients.
>         >> Similar to what a KC
>         >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>         >>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian
>         Thorgersen <
>         >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>         <mailto:sthorger at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from
>         the list on this
>         >>>>>>>>>>>>>>>>>>>>> one.
>         >>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>> Especially around not having any
>         authentication of the
>         >>>>>>>>>>>>>>>>>>>>> clients wanting to
>         >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable
>         comfortable about
>         >>>>>>>>>>>>>>>>>>>>> not securing it and
>         >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user
>         before doing
>         >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>         >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>         >>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>         >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com
>         <mailto:pskopek at redhat.com>> wrote:
>         >>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application
>         initiated
>         >> action
>         >>>>>>>>>>>>>>>>>>>>> (always
>         >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are
>         predefined at
>         >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>         >>>>>>>>>>>>>>>>>>>>>> need for the client/application
>         restriction mechanism.
>         >>>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian
>         Thorgersen <
>         >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>         <mailto:sthorger at redhat.com>>
>         >>>>>>>>>>>>>>>>>>>>>> wrote:
>         >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required
>         actions that are used
>         >>>>>>>>>>>>>>>>>>>>> to prompt the user
>         >>>>>>>>>>>>>>>>>>>>>> to
>         >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with
>         their account after
>         >>>>>>>>>>>>>>>>>>>>> authenticating, but
>         >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the
>         application.
>         >>>>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP,
>         update profile,
>         >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>         >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have
>         to be manually
>         >>>>>>>>>>>>>>>>>>>>> registered with the
>         >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>         >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>         >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all
>         users to verify
>         >>>>>>>>>>>>>>>>>>>>> their email, but
>         >>>>>>>>>>>>>>>>>>>>>> only
>         >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>         >>>>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate
>         actions from the
>         >>>>>>>>>>>>>>>>>>>>> account management
>         >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email
>         address should
>         >>>>>>>>>>>>>>>>>>>>> require verifying the
>         >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>         >>>>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to
>         introduce
>         >>>>>>>>>>>>>>>>>>>>> Application Initiated
>         >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated
>         Action behind the
>         >>>>>>>>>>>>>>>>>>>>> scenes is just a
>         >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>         >>>>>>>>>>>>>>>>>>>>> application and depending on
>         >>>>>>>>>>>>>>>>>>>>>> the
>         >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to
>         complete
>         >>>>>>>>>>>>>>>>>>>>> (where the user can
>         >>>>>>>>>>>>>>>>>>>>>> select
>         >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user
>         back to the
>         >>>>>>>>>>>>>>>>>>>>> application).
>         >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions
>         should perform any
>         >>>>>>>>>>>>>>>>>>>>> updates to the users
>         >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user
>         first. For example
>         >>>>>>>>>>>>>>>>>>>>> an application
>         >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link
>         an existing
>         >>>>>>>>>>>>>>>>>>>>> account to a social
>         >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if
>         they want to
>         >>>>>>>>>>>>>>>>>>>>> link to the provider.
>         >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to
>         integrate these I
>         >>>>>>>>>>>>>>>>>>>>> would like to
>         >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>         applications
>         >>>>>>>>>>>>>>>>>>>>> use to authenticate
>         >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email
>         action the
>         >>>>>>>>>>>>>>>>>>>>> application would redirect
>         >>>>>>>>>>>>>>>>>>>>>> to
>         >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>         kc_action=<action
>         >>>>>>>>>>>>>>>>>>>>> alias> query
>         >>>>>>>>>>>>>>>>>>>>>>> parameter.
>         >>>>>>>>>>>>>>>>>>>>>>>
>         >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is.
>         Assuming all
>         >>>>>>>>>>>>>>>>>>>>> Application Initiated
>         >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first
>         do we need to
>         >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>         >>>>>>>>>>>>>>>>>>>>>>> place to restrict what
>         clients/applications are
>         >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>         >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it
>         harder to use
>         >>>>>>>>>>>>>>>>>>>>> for applications.
>         >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is
>         the ability for
>         >>>>>>>>>>>>>>>>>>>>> an Application
>         >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>         >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>         >>>>>>>>>>>>>>>>>>>>>> performing
>         >>>>>>>>>>>>>>>>>>>>>>> the action. For example update
>         password should
>         >>>>>>>>>>>>>>>>>>>>> require the user to enter
>         >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify
>         email should not
>         >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>         >>>>>>>>>>>>>>>>>>>>>> an
>         >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>         >>>>>>>>>>>>>>>>>>>>>>>
>         _______________________________________________
>         >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>         >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         >>>>>>>>>>>>>>>>>>>>>>>
>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         >>>>>>>>>>>>>>>>>>>>>
>         _______________________________________________
>         >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>         >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         >>>>>>>>>>>>>>>>>>>>>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         >>>>>>>>>>>>>>>>>>>>>
>         >>> _______________________________________________
>         >>> keycloak-dev mailing list
>         >>> keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         >>
>         >> _______________________________________________
>         >> keycloak-dev mailing list
>         >> keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         > _______________________________________________
>         > keycloak-dev mailing list
>         > keycloak-dev at lists.jboss.org
>         <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
>


From mhmd_Alhassan at outlook.sa  Sun Mar 24 11:45:08 2019
From: mhmd_Alhassan at outlook.sa (Mohammed AlHassan)
Date: Sun, 24 Mar 2019 15:45:08 +0000
Subject: [keycloak-dev] Need reviewers for Keycloak Arabic localization
Message-ID: <AM5PR0701MB2292DD6DBBA03E0AC75A40A0AD5D0@AM5PR0701MB2292.eurprd07.prod.outlook.com>

Hi,
I put some effort on translating Keycloak to Arabic as part of a project in my firm. the translation is for login, account, and email themes. my work changes can be found here: https://github.com/Mhmd-Ali/keycloak/commit/49e1d3176b038e4067b6f41b9565e453e32ae723

I though that up-streaming these would be beneficial.I created an issue: https://issues.jboss.org/browse/KEYCLOAK-9373 , but turned out I needed reviewers to my pull request (if I create it). Is there anyone who is willing to volunteer to review the PR? if so this means I can proceed with the PR.

Thanks in advance

From sblanc at redhat.com  Sun Mar 24 13:32:42 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 24 Mar 2019 18:32:42 +0100
Subject: [keycloak-dev] Need reviewers for Keycloak Arabic localization
In-Reply-To: <AM5PR0701MB2292DD6DBBA03E0AC75A40A0AD5D0@AM5PR0701MB2292.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2292DD6DBBA03E0AC75A40A0AD5D0@AM5PR0701MB2292.eurprd07.prod.outlook.com>
Message-ID: <CAMZCGg9F5PNwZK9Qktw9=HDysFGYrQE2SD6Oc-xvrDztO7_=dg@mail.gmail.com>

Hi Mohammed,

Thanks for contributing ! But the easiest to get reviewers is to first
create the PR, after that we will help you to find reviewers.

Seb


On Sun, Mar 24, 2019 at 5:36 PM Mohammed AlHassan <mhmd_Alhassan at outlook.sa>
wrote:

> Hi,
> I put some effort on translating Keycloak to Arabic as part of a project
> in my firm. the translation is for login, account, and email themes. my
> work changes can be found here:
> https://github.com/Mhmd-Ali/keycloak/commit/49e1d3176b038e4067b6f41b9565e453e32ae723
>
> I though that up-streaming these would be beneficial.I created an issue:
> https://issues.jboss.org/browse/KEYCLOAK-9373 , but turned out I needed
> reviewers to my pull request (if I create it). Is there anyone who is
> willing to volunteer to review the PR? if so this means I can proceed with
> the PR.
>
> Thanks in advance
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Mon Mar 25 07:24:58 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Mar 2019 12:24:58 +0100
Subject: [keycloak-dev] X.509 User Identity Extractor - multiple values
In-Reply-To: <AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
References: <DB3PR0502MB399356CAE4CC1C6DC230632CCF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<885bb636-39ac-a77b-799a-6554ba5d74c6@redhat.com>
	<DB3PR0502MB399363166DF589D4DB161904CF420@DB3PR0502MB3993.eurprd05.prod.outlook.com>
	<ee42e442-78c0-3304-0f5d-8fec4c2e3180@redhat.com>
	<AM0PR0502MB39871046FD435ADC4D213A62CF430@AM0PR0502MB3987.eurprd05.prod.outlook.com>
Message-ID: <91fcedac-ccdb-6633-e48c-69cbd6bf9b8d@redhat.com>

On 22/03/2019 11:43, Sven-Torben Janus wrote:
> Hey Marek,
>
> as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac).
Thanks for pointing this. It seems it may be useful to have OOTB 
UserIdentityExtractor, which will work with the MSAD "userCertificate" 
attribute. So if you have a chance to contribute this, I think it will 
be fine.
> IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?

Maybe it is thin line, but in general, I see that having OOTB 
extractors, which are able to pair users based on subjectDN or 
commonName looks natural and will probably work for most of the people. 
Having something very specific like "issuer;serialNumber" is IMO not 
generally useful, so I would rather avoid to have the 
UserIdentityExtractor in Keycloak OOTB.

Marek
>
> Regards
> Sven-Torben
>
> -----Urspr?ngliche Nachricht-----
> Von: Marek Posolda <mposolda at redhat.com>
> Gesendet: Freitag, 22. M?rz 2019 10:20
> An: Sven-Torben Janus <sven-torben.janus at conciso.de>; keycloak-dev at lists.jboss.org
> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values
>
> Thanks for the clarification
>
> TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it.
>
> Marek
>
> On 21/03/2019 17:18, Sven-Torben Janus wrote:
>> Hi Marek,
>>
>> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation.
>> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines).
>>
>> Sven-Torben
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Marek Posolda <mposolda at redhat.com>
>> Gesendet: Donnerstag, 21. M?rz 2019 10:54
>> An: Sven-Torben Janus <sven-torben.janus at conciso.de>;
>> keycloak-dev at lists.jboss.org
>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple
>> values
>>
>> Hi,
>>
>> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )?
>>
>> Marek
>>
>> On 21/03/2019 07:48, Sven-Torben Janus wrote:
>>> Hey all!
>>>
>>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object.
>>>
>>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character.
>>> In addition to that, the whole certificate of the user is also available in another LDAP attribute.
>>>
>>> I currently see the following options to implement a solution for this:
>>> 1) Writing a custom Authenticator to handle that specific situation.
>>> This one would look very similar to the ootb X509 authenticator, but
>>> implements either a) or b) (see below)
>>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors.
>>>
>>> For both approaches two different implementations come to my mind:
>>>
>>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity.
>>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity.
>>>
>>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful.
>>>
>>> Do you have any advice on which way to go here?
>>>
>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/main
>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityExt
>>> ractor.java
>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/main
>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityToM
>>> odelMapper.java#L57
>>>
>>> Regards
>>> Sven-Torben
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From kschwiersch at yahoo.de  Mon Mar 25 07:51:35 2019
From: kschwiersch at yahoo.de (Ken Haendel)
Date: Mon, 25 Mar 2019 12:51:35 +0100
Subject: [keycloak-dev] Reset Password does not give feedback on success
Message-ID: <1027be18-823f-a708-d10c-1bb92bffa84b@yahoo.de>

I have a problem using keycloak 4.8.3

If a user wants to reset his password, he clicks on the 
reset-password-link and a browser opens with the "Update password" page.

After the form is submitted the user still remains on the "Update 
password" page and is not informed about the positive result

So, the question is: is it intended to give no feedback here? Or is it a 
known bug?


Thank you in advance,

Ken



From sblanc at redhat.com  Mon Mar 25 07:57:41 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 25 Mar 2019 12:57:41 +0100
Subject: [keycloak-dev] Reset Password does not give feedback on success
In-Reply-To: <1027be18-823f-a708-d10c-1bb92bffa84b@yahoo.de>
References: <1027be18-823f-a708-d10c-1bb92bffa84b@yahoo.de>
Message-ID: <CAMZCGg-PMHxMPXgAnne_BHJdH7jB98L=_yT8Bjboz-s8-g3NBw@mail.gmail.com>

Hi,

Please use the keycloak-user mailing list for usage related questions. This
list is intended for keycloak project development questions.

Sebi

On Mon, Mar 25, 2019 at 12:53 PM Ken Haendel <kschwiersch at yahoo.de> wrote:

> I have a problem using keycloak 4.8.3
>
> If a user wants to reset his password, he clicks on the
> reset-password-link and a browser opens with the "Update password" page.
>
> After the form is submitted the user still remains on the "Update
> password" page and is not informed about the positive result
>
> So, the question is: is it intended to give no feedback here? Or is it a
> known bug?
>
>
> Thank you in advance,
>
> Ken
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bsuzuki at amplify.com  Mon Mar 25 20:57:16 2019
From: bsuzuki at amplify.com (Brandon Suzuki)
Date: Mon, 25 Mar 2019 20:57:16 -0400
Subject: [keycloak-dev] SAML attribute to session attribute mapper
Message-ID: <CADfdB8rHm2M5SRjv2ew6r2NpG1+Xnqihhcx4noJrY05BXzAJ1w@mail.gmail.com>

Hi, would a SAML attribute to session attribute (note) provider mapper be
worth submitting upstream?  We plan to create one so were wondering if it
would be useful enough to others.

Thanks,
Brandon

-- 
bsuzuki at amplify.com
Amplify
55 Washington Street, 8th floor
Brooklyn, NY 11201-1071
amplify.com <http://www.amplify.com/>

From sthorger at redhat.com  Tue Mar 26 03:45:51 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Mar 2019 08:45:51 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <f26ca599-2d4f-ebab-daea-b900f0317b01@redhat.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJrcDBfu3o0PWHFLsXmqZ1zEy1rtyfQjvFe=c9uoVVuONMtA-Q@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<f26ca599-2d4f-ebab-daea-b900f0317b01@redhat.com>
Message-ID: <CAJgngAfHmt-iW6haibvbkrHPyqokaX9hVQwzMs3uUhokGirEag@mail.gmail.com>

On Fri, 22 Mar 2019 at 15:12, Marek Posolda <mposolda at redhat.com> wrote:

> On 22/03/2019 12:42, Stian Thorgersen wrote:
>
>
>
> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I am sorry to join this so late.
>>
>> My concern is, that in the design, it was mentioned that consent will be
>> always required from the user. I understand that this simplifies the
>> flow as it's more secure and not need to authenticate the client.
>> However from the usability perspective, it doesn't look so nice to me.
>>
>> For example assume that in the application, the user just clicked on the
>> button "Link my account with Facebook" . Then after login with Facebook,
>> he will see another splash screen like "Application XY wants to link
>> your account with Facebook", which he needs to confirm. It may be
>> especially bad for usability in this case with linking social accounts,
>> as user may see one splash screen shown by Facebook "Application
>> keycloak wants to access your Facebook profile and email" and then
>> immediately another splash screen shown by Keycloak "Application Foo
>> wants to link your account with Facebook" .
>>
>> Maybe I am wrong, but my guess is, that our users will very quickly come
>> with requirement "Can I ommit to show the splash screen?" . It is bit
>> similar to the "Consent Required" switch, which I guess most people have
>> OFF for their clients. So IMO I would rather count with this from the
>> beginning and count with the fact, that we will need to ommit consent
>> screen and hence verify client.
>>
>> With regards to this, It seems that we may need also to specify if
>> client is:
>> - Allowed to initiate action
>> - Allowed to initate action with the consent required
>> - Allowed to initate action with no-consent required
>> Maybe the "Consent required" switch can be on instead on the action
>> itself, but the will still need to restrict if client is allowed or not
>> to perform the action.
>>
>
> I can see your point for linking to external IdP.
>
> However, for everything else the actions are requesting a user to enter
> information before something happens. I.e. registering WebAuthn device,
> update password, etc.. All require the user to first fill in the form.
>
> I see. But if we can think about at least of one "type" of the action,
> which may not show any special page, there are probably others :)
>
> With regards to the flow, I suggest that KC will require full
>> OIDC/OAuth2 flow. In other words, when KC redirects back to the client,
>> the client will be required to send code-to-token request. And the
>> action (EG. Keycloak user linked with Facebook) is done *after* the
>> whole flow (including code-to-token flow) is finished. That should be
>> sufficient to verify the client and at the same time, it will allow us
>> to add some more things to tokens (EG. some facebook details) . Downside
>> is, that it will be harder to implement though as the SPI will likely
>> need another callback after code-to-token flow to "finish" the action...
>>
>
> I don't think I understand, because if you are proposing what I'm thinking
> it sounds awkward. Can you list the flow?
>
> It is pretty much OIDC flow. So:
>
> - The initial request with "kc_action=link-facebook" is sent to OIDC
> authentication endpoint
> - KC (re-)authenticates user and do all the UI actions required for the
> requested action
> - Before the model is updated (EG. userModel.addFederationLink("facebook")
> called), there is redirection to client with code+state etc
> - Client needs to send code-to-token request.
> - KC will need to verify code (already done), finally finish the model
> (EG. call "user.addFederationLink" or "user.setEmailVerified(true)" ).
> That's where I think the SPI callback will be needed. Finally re-generate
> tokens and verify back to the application.
> - Client receives updated tokens with all the new state (EG.
> "email_verified" is set to true, user's birthday claim retrieved from
> facebook is in the token etc.)
>
> This has some good advantages like the:
>
> - Client is verified. In case of confidential clients, there is proper
> client authentication. For public clients, there is at least redirection
> back to the client application and exchanging for tokens, which is still
> bit safer than just update model on server (EG.
> userModel.addFederationLink) and redirect to client after. However for
> public clients, people will more likely want to show the splash screen
> "Application XY wants to link your account"
>
> - Tokens are updated at the end of the flow. This is important for many
> applications though as in many cases, people will likely trigger actions
> under some conditions. For example in the application will do something
> like:
>
> if (!idToken.isEmailVerified()) {
>     redirectToVerifyEmailAction();
>
> }
>
> So without updated tokens, you will have infinite loop or the need to
> re-trigger to OIDC flow manually again to have tokens refreshed with new
> claims
>
I really hate that idea ;)

* You don't know the client until after the user has entered the values -
so invalid client would still require user to do the work, but just
silently revert it
* Requires special actions that somehow caches all updates
* May be very hard to do for some actions

I could go on


>
>
>>
>> Last thing, I was thinking about using "scope" parameter to reference
>> those actions instead of have proprietary "kc_action" thing. The we
>> don't need any extensions of OIDC. It may simplify things like consents
>> etc. Also client will be able to have something similar like we have in
>> "Client Scopes" tab - the list of action, which he is allowed to
>> initiate. But I am not sure about this last point and maybe it's better
>> to keep things separated...
>>
>
> I'm not convinced using scope param makes sense. It just doesn't fit in my
> mental model.
>
> I see. I am also not convinced so much about scope param... Just some
> quick idea :)
>
> Marek
>
>
>
>>
>> Marek
>>
>>
>>
>>
>> On 21/03/2019 14:07, Pedro Igor Silva wrote:
>> > Sure, I'm not against the initial design/scope. Just tried to make
>> comments
>> > about other aspects that, to me, are related or how it can be leveraged
>> to
>> > also achieve other things.
>> >
>> > So, what Stian plans mentioned in one of his replies is fine for me.
>> >
>> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> >
>> >> Pedro,
>> >>
>> >> My only concern is getting this nailed down so we can move forward with
>> >> the new account console.
>> >>
>> >> It sounds like Stian's proposal is simpler, but covers fewer use cases.
>> >> Is that correct?
>> >>
>> >> Would it be practical to implement Stian's plan and then implement your
>> >> proposal at a later date?
>> >>
>> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>> >>> In addition to everything you said.
>> >>>
>> >>> * It is not only about making changes to account, but updating tokens
>> >> with
>> >>> information from required actions, which not necessarily need to be
>> >>> persisted.
>> >>>
>> >>> * For back-end applications, we could also associate these required
>> >> actions
>> >>> with scopes. If we could have a required action as "Re-authenticate"
>> or
>> >>> "Provide 2nd factor", that would also help with step-up
>> authentication.
>> >> As
>> >>> an alternative to OIDC acr related parameters/claims. I don't think it
>> >>> makes sense to bring to the client concerns that are really tied to
>> the
>> >>> scopes of a resource server. As I said, clients should ask for scopes
>> and
>> >>> Keycloak should do whatever is necessary to grant these (via consent,
>> via
>> >>> additional steps/actions). Consider what you mentioned at the end of
>> your
>> >>> design document at "Require Re-Authentication". Couldn't we leverage
>> AIA
>> >>> for step-up and ask the user for a more stronger credential ?
>> >>>
>> >>> * Claims gathering flow is simple. The Keycloak server would return
>> the
>> >>> endpoint to where the client should redirect the user. After obtaining
>> >>> information from the user, Keycloak would issue a ticket (instead of
>> >> code).
>> >>> The endpoint returned by Keycloak would contain the action associated
>> >> with
>> >>> a resource. The endpoint could be the same as what you are using for
>> AIA.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <sthorger at redhat.com
>> >
>> >>> wrote:
>> >>>
>> >>>> Pedro,
>> >>>>
>> >>>> I really don't understand what your points are and what you propose
>> we
>> >> do
>> >>>> here.
>> >>>>
>> >>>> The use-case we're addressing is the following:
>> >>>>
>> >>>> As a user I would like to initiate an action associated with my
>> account
>> >>>> through a front-end application so that I can make changes to my
>> >> account,
>> >>>> for example to register a WebAuthn security key with my account.
>> >>>>
>> >>>> Further, we want an action to be implemented once and re-usable in
>> >>>> login/registration flows as well as from applications managing user
>> >>>> accounts, incuding our new account console. That means our new
>> account
>> >>>> console needs to be able to invoke an action in the login flow,
>> >> otherwise
>> >>>> we would have to implement actions as react/rest also.
>> >>>>
>> >>>> Now the solution I have proposed is simple. It allows an application
>> to
>> >>>> request an action being invoked after the user has authenticated.
>> Think
>> >> of
>> >>>> it as a "required action" on-demand. It can be implemented with a few
>> >> lines
>> >>>> of code and easily tested. It is very easy to use as it just means
>> >> adding
>> >>>> an extra query param to the login flows, which makes it very easy to
>> use
>> >>>> both for confidential and non-confidential clients.
>> >>>>
>> >>>> It is not trying to cover claims gathering use-case from UMA. I see
>> no
>> >>>> connection to this and step-up authentication. These both already
>> have
>> >>>> clearly defined protocols. Neither can be used to address the above
>> >>>> use-case.
>> >>>>
>> >>>> So please come with a concrete proposal as I have no clue what your
>> >>>> objections are.
>> >>>>
>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <
>> sthorger at redhat.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <
>> psilva at redhat.com>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <
>> psilva at redhat.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>> >>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Is it this stuff you're thinking about:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>
>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>> >>>>>>>>>>>>   From that it does a get including the ticket as a query
>> >> parameter.
>> >>>>>>>>>>>> I don't like the idea of sending tickets as query params as
>> >> they could be
>> >>>>>>>>>>>> logged. For the application initiated action it would have to
>> >> be an ID
>> >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps we
>> >> have a way of
>> >>>>>>>>>>>> creating a ticket that can only be used to initiate an
>> action.
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Why you need to send the id token if the client already got
>> an id
>> >>>>>>>>>>> token and, considering browser flow, there is a cookie that
>> can
>> >> be used by
>> >>>>>>>>>>> Keycloak to identify the client/user ?
>> >>>>>>>>>>>
>> >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>> >>>>>>>>>>
>> >>>>>>>>> But the identity cookie has the user session and from it we can
>> >> check
>> >>>>>>>>> whether or not the client initiating the action (client_id) has
>> a
>> >>>>>>>>> authenticated client session, no ?
>> >>>>>>>>>
>> >>>>>>>> That only proves that the client_id belongs to a client that has
>> >>>>>>>> obtained a token. It doesn't authenticate the client in any way.
>> >>>>>>>>
>> >>>>>>>> Q- Why is authentication of the client required? IMO it is not
>> >>>>>>>> required.
>> >>>>>>>>
>> >>>>>>> Sure, but the client obtained token and is authenticated, thus
>> acting
>> >>>>>>> on behalf of the user. If the client is already acting on behalf
>> of
>> >> a user,
>> >>>>>>> we don't need to authenticate it.
>> >>>>>>>
>> >>>>>> That's not correct. All we know is that a client with the same
>> >> client_id
>> >>>>>> has obtained a token. Anyone can use the same client_id to
>> initiate an
>> >>>>>> action.
>> >>>>>>
>> >>>>>>
>> >>>>>>>>>>>> Perhaps what we could do is:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> 1. By default any application can initiate an action
>> >>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of
>> any
>> >>>>>>>>>>>> sort, just a regular oauth flow
>> >>>>>>>>>>>> 2. Later add support if demand to limit what applications can
>> >>>>>>>>>>>> initiate actions
>> >>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>> >>>>>>>>>>>> everyone then no need for a ticket
>> >>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>> >>>>>>>>>>>> applications we would need some form of authentication.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA
>> claim
>> >>>>>>>>>>>> redirect does
>> >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>> >> endpoint
>> >>>>>>>>>>>> using an id token as bearer token
>> >>>>>>>>>>>> c. Add a note into client session with a initiate action
>> ticket
>> >>>>>>>>>>>> for clients that can initiate actions and map this into the
>> id
>> >> token.
>> >>>>>>>>>>> Not sure ...
>> >>>>>>>>>>>
>> >>>>>>>>>>> If you think about it, the part interested in obtaining the
>> >> claims
>> >>>>>>>>>>> after an action is completed is not the client but the
>> audience
>> >> of the
>> >>>>>>>>>>> token, the resource server. In this case, the UMA approach
>> seems
>> >> more
>> >>>>>>>>>>> appropriate because the resource server is in control about
>> what
>> >> actions
>> >>>>>>>>>>> the client should initiate in order to fulfill the constraints
>> >> imposed by
>> >>>>>>>>>>> the resource server to access its protected resources. Where
>> >> these
>> >>>>>>>>>>> constraints could be a DOB in the token or a higher security
>> >> level.
>> >>>>>>>>>>> The app initiating actions in the server is not the goal, but
>> the
>> >>>>>>>>>>> tool to obtain additional claims from the server ...
>> >>>>>>>>>>>
>> >>>>>>>>>>> However, for some applications acting as both client and
>> resource
>> >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket dance
>> >> and just
>> >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>> >>>>>>>>>>>
>> >>>>>>>>>> Perhaps there's a case for that, but that would be claims
>> >> gathering,
>> >>>>>>>>>> not application initiated actions.
>> >>>>>>>>>>
>> >>>>>>>>>> Application initiated actions are more a tool for folks to add
>> >>>>>>>>>> actions for the user account into their own GUIs, and as such
>> >> should be a
>> >>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
>> >> have any
>> >>>>>>>>>> flows between app and service, but rather just allows the app
>> to
>> >> get the
>> >>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>> >>>>>>>>>>
>> >>>>>>>>> I think claims gathering and AIA are pretty much the same thing.
>> >> Both
>> >>>>>>>>> are querying the user for additional information. Despite if you
>> >> are
>> >>>>>>>>> initiating an action to request user's DOB or update a password,
>> >> they are
>> >>>>>>>>> steps that the user must perform in order to enrich its security
>> >> context
>> >>>>>>>>> and be able to continue using both client and resource server.
>> >>>>>>>>>
>> >>>>>>>>> The point I'm trying to make is that AIA can solve other
>> problems
>> >>>>>>>>> too. You would still solve the original problem from your design
>> >> document
>> >>>>>>>>> as defined in the motivation section. While you would also help
>> >> with
>> >>>>>>>>> step-up authentication and UMA claims gathering. Another point
>> is
>> >> related
>> >>>>>>>>> to the party interested in the action. Is it the client or the
>> >> resource
>> >>>>>>>>> server (the API)?
>> >>>>>>>>>
>> >>>>>>>>> If the client (which honestly I don't see much use as most apps
>> >> seem
>> >>>>>>>>> to be a combination of front-end + back-end, where the
>> >> functionality is
>> >>>>>>>>> provided by the back-end and protected by a bearer token) then
>> you
>> >> may just
>> >>>>>>>>> consider passing the "kc_action" parameter and have the action
>> >> initiated.
>> >>>>>>>>> If the resource server, you could associate the required actions
>> >> with
>> >>>>>>>>> the scopes. So when a client requests a specific scope, Keycloak
>> >> will start
>> >>>>>>>>> the action(s) and query the user for some information prior to
>> >> issuing the
>> >>>>>>>>> access token.
>> >>>>>>>>>
>> >>>>>>>>> Still, if the resource server, the resource server could
>> respond to
>> >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
>> >> then the
>> >>>>>>>>> client will just redirect the user to the location provided in
>> the
>> >> response
>> >>>>>>>>> to initiate the actions.
>> >>>>>>>>>
>> >>>>>>>> I don't understand what your point is or what you are proposing
>> >> here.
>> >>>>>>> And I do understand your point of view. I just think that it can
>> do
>> >>>>>>> much more than address new account management console
>> requirements.
>> >>>>>>>
>> >>>>>>> Based on your design document, I understand what you described in
>> the
>> >>>>>>> Motivation section. But again, instead of considering the "two
>> >> things" that
>> >>>>>>> originated the idea behind AIA, I think we can take the
>> opportunity
>> >> and do
>> >>>>>>> much more. As they seem related to me. Especially after your DOB
>> >> example.
>> >>>>>> I don't see the additional use-cases you are mentioning as related
>> at
>> >>>>>> all.
>> >>>>>>
>> >>>>> How it is not related ? The audience of the information gathered
>> during
>> >>>>> the AIA does impact where the token with the information will be
>> used.
>> >> If I
>> >>>>> need a DOB to access some page in my front-end, this is one thing.
>> If I
>> >>>>> need DOB to access some resource protected by a resource server it
>> is
>> >>>>> another thing. Both require tokens with different audiences, the
>> former
>> >>>>> will probably be an ID Token where the latter the access token.
>> >>>>>
>> >>>>> In OAuth2 the scopes represent the permissions to access protected
>> >>>>> resources. Thus, it does make sense to have required actions that
>> can
>> >>>>> challenge a user when requesting scopes. Considering your DOB
>> example,
>> >> if
>> >>>>> my client wants to access resource /api/age/check why you want the
>> >> client
>> >>>>> to request kc_action=dob if the scope "dob" is what he needs to
>> access
>> >> the
>> >>>>> API ? Otherwise, you are making the client aware of things that are
>> >> really
>> >>>>> related to the resource server. It is OK the client ask for scope
>> >> "age", it
>> >>>>> is how OAuth2 authorization model works.
>> >>>>>
>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>> >> client
>> >>>>> really dumb about what it needs to access protected resources. With
>> >> UMA,
>> >>>>> the client will just receive a ticket and with that ticket it can
>> >> perform
>> >>>>> the necessary actions to make a successful authorization request to
>> the
>> >>>>> server.
>> >>>>>
>> >>>>>
>> >>>>>> * Step-up authentication has already clear parameters in
>> OIDC/OAuth to
>> >>>>>> request high level of authentication. On the implementation side
>> it's
>> >> about
>> >>>>>> invoking additional parts of the authentication flow, not to
>> initiate
>> >> an
>> >>>>>> required action that has nothing to do with the authentication
>> flow.
>> >>>>>>
>> >>>>> Can we consider a required action as a prompt for 2nd factor, for
>> >>>>> instance ?
>> >>>>>
>> >>>>>
>> >>>>>> * Claims gathering in UMA is about asking the user for additional
>> >>>>>> claims. AIA can be used as a poor-mans workaround to lack of claims
>> >>>>>> gathering, but end of the day it's completely different. AIA will
>> >> allow an
>> >>>>>> app to invoke the action update_DOB, while claims gaterhing will
>> >> allow the
>> >>>>>> application to request the claim DOB.
>> >>>>>>
>> >>>>> Not sure, if the difference is due to updating a piece of info, both
>> >>>>> flows request the user for the info. Is just a matter of updating or
>> >> not
>> >>>>> updating the info.
>> >>>>>
>> >>>>>
>> >>>>>> I don't see what additional things we need to consider for
>> something
>> >>>>>> that is in the end very simple and can be implemented in a couple
>> >> hours
>> >>>>>> including tests if we don't try to make it more complicated.
>> >>>>>>
>> >>>>>>
>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>> >> sthorger at redhat.com>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>> >> psilva at redhat.com>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
>> required?
>> >>>>>>>>>>>>>>>>> The user will be prompted before making an action and
>> it's
>> >> an action they
>> >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically visible/exposed
>> to
>> >> the client.
>> >>>>>>>>>>>>>>>> The client is making the request and even though the
>> user is
>> >>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
>> >> want to restrict
>> >>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That
>> is
>> >> what I mean by
>> >>>>>>>>>>>>>>>> some level of authorization.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> You could even consider not authenticating the client at
>> >> all,
>> >>>>>>>>>>>>>>>> but still allow admins to enforce which clients should be
>> >> allowed to
>> >>>>>>>>>>>>>>>> initiate actions on the server.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>> >> initiate
>> >>>>>>>>>>>>>>> actions will work without authenticating the client.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>> >>>>>>>>>>>>>> discussing. This is more a validation of the client making
>> >> the request.
>> >>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
>> >> client_id and
>> >>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
>> >> doing browser
>> >>>>>>>>>>>>>> authentication the cookie is already present) and possibly
>> >> add some level
>> >>>>>>>>>>>>>> of authorization to enforce which clients can perform
>> actions
>> >> (instead of
>> >>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris
>> are
>> >> really
>> >>>>>>>>>>>>>> important because you want to make sure the redirect uri is
>> >> valid before
>> >>>>>>>>>>>>>> redirecting the user.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>> >>>>>>>>>>>>> redirect_uris are already being checked. It's just a
>> standard
>> >> OAuth flow.
>> >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>> >> clients
>> >>>>>>>>>>>>> can initiate actions. If that's needed then we need
>> something
>> >> more
>> >>>>>>>>>>>>> complicated that properly authenticates the client, as
>> anyone
>> >> could just
>> >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>> >> application to get the
>> >>>>>>>>>>>>> action initiated (although wouldn't then have the user
>> >> redirected back to
>> >>>>>>>>>>>>> the app of course).
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints
>> like
>> >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
>> >> user will be
>> >>>>>>>>>>>>>>>>>> redirected back after the action completes). But still,
>> >> we could also add
>> >>>>>>>>>>>>>>>>>> some level authorization.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone
>> can
>> >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a different
>> >> client.
>> >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>> >> happens
>> >>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
>> >> back to the client
>> >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure
>> that
>> >> the client is
>> >>>>>>>>>>>>>>>> known and that the user will be redirected back to a
>> valid
>> >> URI.
>> >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new
>> tokens.
>> >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
>> >> client wants that,
>> >>>>>>>>>>>>>>> then they can request the user to enter a DOB, which would
>> >> then result in
>> >>>>>>>>>>>>>>> the DOB being available in the token.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> This flow seems very closely related with the Claims
>> Gathering
>> >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is there
>> >> and see if it
>> >>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> Go for it ;)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>> >> where
>> >>>>>>>>>>>>>>>>> the application can request a token to initate an
>> action.
>> >> So flow would be:
>> >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID Token
>> as
>> >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>> >> return a single use
>> >>>>>>>>>>>>>>>>> token.
>> >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>> >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>> >> "?action-token=<action token>"
>> >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId) function
>> >> that
>> >>>>>>>>>>>>>>>>> would get the action token before redirecting the user.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients
>> and
>> >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate actions
>> >> may be public
>> >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol
>> for
>> >> this, but rather
>> >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate
>> the
>> >>>>>>>>>>>>>>>>>>> client?
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>> >>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>> >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as simple
>> >> as leveraging authz
>> >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>> >> Similar to what a KC
>> >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on
>> this
>> >>>>>>>>>>>>>>>>>>>>> one.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of
>> the
>> >>>>>>>>>>>>>>>>>>>>> clients wanting to
>> >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable
>> about
>> >>>>>>>>>>>>>>>>>>>>> not securing it and
>> >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>> >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>> >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>> >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
>> >> action
>> >>>>>>>>>>>>>>>>>>>>> (always
>> >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined
>> at
>> >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>> >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
>> mechanism.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>> >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>> >>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are
>> used
>> >>>>>>>>>>>>>>>>>>>>> to prompt the user
>> >>>>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account
>> after
>> >>>>>>>>>>>>>>>>>>>>> authenticating, but
>> >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>> >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>> >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be
>> manually
>> >>>>>>>>>>>>>>>>>>>>> registered with the
>> >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>> >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>> >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to
>> verify
>> >>>>>>>>>>>>>>>>>>>>> their email, but
>> >>>>>>>>>>>>>>>>>>>>>> only
>> >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>> >>>>>>>>>>>>>>>>>>>>> account management
>> >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>> >>>>>>>>>>>>>>>>>>>>> require verifying the
>> >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>> >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind
>> the
>> >>>>>>>>>>>>>>>>>>>>> scenes is just a
>> >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>> >>>>>>>>>>>>>>>>>>>>> application and depending on
>> >>>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>> >>>>>>>>>>>>>>>>>>>>> (where the user can
>> >>>>>>>>>>>>>>>>>>>>>> select
>> >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>> >>>>>>>>>>>>>>>>>>>>> application).
>> >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform
>> any
>> >>>>>>>>>>>>>>>>>>>>> updates to the users
>> >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For
>> example
>> >>>>>>>>>>>>>>>>>>>>> an application
>> >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
>> >>>>>>>>>>>>>>>>>>>>> account to a social
>> >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want to
>> >>>>>>>>>>>>>>>>>>>>> link to the provider.
>> >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate
>> these I
>> >>>>>>>>>>>>>>>>>>>>> would like to
>> >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>> applications
>> >>>>>>>>>>>>>>>>>>>>> use to authenticate
>> >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>> >>>>>>>>>>>>>>>>>>>>> application would redirect
>> >>>>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>> kc_action=<action
>> >>>>>>>>>>>>>>>>>>>>> alias> query
>> >>>>>>>>>>>>>>>>>>>>>>> parameter.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming
>> all
>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>> >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need to
>> >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>> >>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>> >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>> >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to use
>> >>>>>>>>>>>>>>>>>>>>> for applications.
>> >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the ability
>> for
>> >>>>>>>>>>>>>>>>>>>>> an Application
>> >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>> >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>> >>>>>>>>>>>>>>>>>>>>>> performing
>> >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>> >>>>>>>>>>>>>>>>>>>>> require the user to enter
>> >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should
>> not
>> >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>> >>>>>>>>>>>>>>>>>>>>>> an
>> >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>> >>>>>>>>>>>>>>>>>>>>>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>>>>>>>>>>>>>>>>>>
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Tue Mar 26 03:53:55 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Mar 2019 08:53:55 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
	<ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>
Message-ID: <CAJgngAc5mxJg5mg0pgQFO5hWu4H=QbUF5Dt_zB3enPAX5xauqg@mail.gmail.com>

I'm going to remind everyone again what is the aim and scope of AIA:

* It is for an application to initiate an action, period.
* It is aimed at allowing external account console (and similar
applications) to make it possible for users to make changes to their
account where we want to delegate the logic to actions after the "login
flow" rather than having to duplicate the work in rest endpoints as well as
"login flows"

That is it. The design of this feature keeps getting more and more complex
and we're not getting anywhere in the discussion because people are
suggesting nice-to-haves or hypothetical other use-cases for the feature.
So please keep the original use-case in mind when you are commenting on
this and let's not make this into a complex unusable jack of all trades,
but rather keep it as something simple with a small narrow use-case.

On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda at redhat.com> wrote:

> On 22/03/2019 12:49, Stian Thorgersen wrote:
>
> To authenticate the client, why don't we just require id_token_hint to be
> included?
>
> We would require the ID token to be issued to the client trying to
> initiate the action and also be associated with the current session.
>
> I'd say we don't need to finely control what clients can do what at least
> not for now. Client should have scope on the manage_account role and that's
> enough for now.
>
> This assumes that client is authenticated before action is triggered.
> Don't we want also a possibility to trigger this "Application Initiated
> Actions" for cases when user is not yet authenticated? For example if I
> have web application, which will be something like "Web Email client", I
> want to ensure that user always has email verified before he is redirected
> to my application as authenticated. So I may want to trigger OIDC flow with
> "kc_action" even before user is authenticated.
>
A few points here:

* AIA are there to specifically run an action, not to request some sort of
condition on the user account. kc_action=verify_email would run the verify
email regardless if email is verified or not.
* AIA are there for an application to allow a user to initiate an action
from within an external app. It's not really there for the app to request
things out of bounds.


> Will be also nice for the "Terms and Conditions" actions as the "Terms and
> Conditions" pages are often client specific, so our current approach with
> generic "Terms and Conditions" action is likely not so nice and requires
> that many application implements some equivalent of app-specific "Terms and
> Conditions" page on their side rather than rely on Keycloak. But with those
> "Application Initiated Actions" we can improve on here.
>
As far as I know we have never had a request for client specific terms and
conditions. Not sure that is something Keycloak should ever consider,
besides if we did that doesn't need kc_action, but rather just some way to
configure different terms based on the client.

> Marek
>
>
> On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> I am sorry to join this so late.
>>>
>>> My concern is, that in the design, it was mentioned that consent will be
>>> always required from the user. I understand that this simplifies the
>>> flow as it's more secure and not need to authenticate the client.
>>> However from the usability perspective, it doesn't look so nice to me.
>>>
>>> For example assume that in the application, the user just clicked on the
>>> button "Link my account with Facebook" . Then after login with Facebook,
>>> he will see another splash screen like "Application XY wants to link
>>> your account with Facebook", which he needs to confirm. It may be
>>> especially bad for usability in this case with linking social accounts,
>>> as user may see one splash screen shown by Facebook "Application
>>> keycloak wants to access your Facebook profile and email" and then
>>> immediately another splash screen shown by Keycloak "Application Foo
>>> wants to link your account with Facebook" .
>>>
>>> Maybe I am wrong, but my guess is, that our users will very quickly come
>>> with requirement "Can I ommit to show the splash screen?" . It is bit
>>> similar to the "Consent Required" switch, which I guess most people have
>>> OFF for their clients. So IMO I would rather count with this from the
>>> beginning and count with the fact, that we will need to ommit consent
>>> screen and hence verify client.
>>>
>>> With regards to this, It seems that we may need also to specify if
>>> client is:
>>> - Allowed to initiate action
>>> - Allowed to initate action with the consent required
>>> - Allowed to initate action with no-consent required
>>> Maybe the "Consent required" switch can be on instead on the action
>>> itself, but the will still need to restrict if client is allowed or not
>>> to perform the action.
>>>
>>
>> I can see your point for linking to external IdP.
>>
>> However, for everything else the actions are requesting a user to enter
>> information before something happens. I.e. registering WebAuthn device,
>> update password, etc.. All require the user to first fill in the form.
>>
>>
>>>
>>> With regards to the flow, I suggest that KC will require full
>>> OIDC/OAuth2 flow. In other words, when KC redirects back to the client,
>>> the client will be required to send code-to-token request. And the
>>> action (EG. Keycloak user linked with Facebook) is done *after* the
>>> whole flow (including code-to-token flow) is finished. That should be
>>> sufficient to verify the client and at the same time, it will allow us
>>> to add some more things to tokens (EG. some facebook details) . Downside
>>> is, that it will be harder to implement though as the SPI will likely
>>> need another callback after code-to-token flow to "finish" the action...
>>>
>>
>> I don't think I understand, because if you are proposing what I'm
>> thinking it sounds awkward. Can you list the flow?
>>
>>
>>>
>>> Last thing, I was thinking about using "scope" parameter to reference
>>> those actions instead of have proprietary "kc_action" thing. The we
>>> don't need any extensions of OIDC. It may simplify things like consents
>>> etc. Also client will be able to have something similar like we have in
>>> "Client Scopes" tab - the list of action, which he is allowed to
>>> initiate. But I am not sure about this last point and maybe it's better
>>> to keep things separated...
>>>
>>
>> I'm not convinced using scope param makes sense. It just doesn't fit in
>> my mental model.
>>
>>
>>>
>>> Marek
>>>
>>>
>>>
>>>
>>> On 21/03/2019 14:07, Pedro Igor Silva wrote:
>>> > Sure, I'm not against the initial design/scope. Just tried to make
>>> comments
>>> > about other aspects that, to me, are related or how it can be
>>> leveraged to
>>> > also achieve other things.
>>> >
>>> > So, what Stian plans mentioned in one of his replies is fine for me.
>>> >
>>> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> >
>>> >> Pedro,
>>> >>
>>> >> My only concern is getting this nailed down so we can move forward
>>> with
>>> >> the new account console.
>>> >>
>>> >> It sounds like Stian's proposal is simpler, but covers fewer use
>>> cases.
>>> >> Is that correct?
>>> >>
>>> >> Would it be practical to implement Stian's plan and then implement
>>> your
>>> >> proposal at a later date?
>>> >>
>>> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>> >>> In addition to everything you said.
>>> >>>
>>> >>> * It is not only about making changes to account, but updating tokens
>>> >> with
>>> >>> information from required actions, which not necessarily need to be
>>> >>> persisted.
>>> >>>
>>> >>> * For back-end applications, we could also associate these required
>>> >> actions
>>> >>> with scopes. If we could have a required action as "Re-authenticate"
>>> or
>>> >>> "Provide 2nd factor", that would also help with step-up
>>> authentication.
>>> >> As
>>> >>> an alternative to OIDC acr related parameters/claims. I don't think
>>> it
>>> >>> makes sense to bring to the client concerns that are really tied to
>>> the
>>> >>> scopes of a resource server. As I said, clients should ask for
>>> scopes and
>>> >>> Keycloak should do whatever is necessary to grant these (via
>>> consent, via
>>> >>> additional steps/actions). Consider what you mentioned at the end of
>>> your
>>> >>> design document at "Require Re-Authentication". Couldn't we leverage
>>> AIA
>>> >>> for step-up and ask the user for a more stronger credential ?
>>> >>>
>>> >>> * Claims gathering flow is simple. The Keycloak server would return
>>> the
>>> >>> endpoint to where the client should redirect the user. After
>>> obtaining
>>> >>> information from the user, Keycloak would issue a ticket (instead of
>>> >> code).
>>> >>> The endpoint returned by Keycloak would contain the action associated
>>> >> with
>>> >>> a resource. The endpoint could be the same as what you are using for
>>> AIA.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <
>>> sthorger at redhat.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Pedro,
>>> >>>>
>>> >>>> I really don't understand what your points are and what you propose
>>> we
>>> >> do
>>> >>>> here.
>>> >>>>
>>> >>>> The use-case we're addressing is the following:
>>> >>>>
>>> >>>> As a user I would like to initiate an action associated with my
>>> account
>>> >>>> through a front-end application so that I can make changes to my
>>> >> account,
>>> >>>> for example to register a WebAuthn security key with my account.
>>> >>>>
>>> >>>> Further, we want an action to be implemented once and re-usable in
>>> >>>> login/registration flows as well as from applications managing user
>>> >>>> accounts, incuding our new account console. That means our new
>>> account
>>> >>>> console needs to be able to invoke an action in the login flow,
>>> >> otherwise
>>> >>>> we would have to implement actions as react/rest also.
>>> >>>>
>>> >>>> Now the solution I have proposed is simple. It allows an
>>> application to
>>> >>>> request an action being invoked after the user has authenticated.
>>> Think
>>> >> of
>>> >>>> it as a "required action" on-demand. It can be implemented with a
>>> few
>>> >> lines
>>> >>>> of code and easily tested. It is very easy to use as it just means
>>> >> adding
>>> >>>> an extra query param to the login flows, which makes it very easy
>>> to use
>>> >>>> both for confidential and non-confidential clients.
>>> >>>>
>>> >>>> It is not trying to cover claims gathering use-case from UMA. I see
>>> no
>>> >>>> connection to this and step-up authentication. These both already
>>> have
>>> >>>> clearly defined protocols. Neither can be used to address the above
>>> >>>> use-case.
>>> >>>>
>>> >>>> So please come with a concrete proposal as I have no clue what your
>>> >>>> objections are.
>>> >>>>
>>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>>> >> wrote:
>>> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <
>>> sthorger at redhat.com>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <psilva at redhat.com
>>> >
>>> >>>>>> wrote:
>>> >>>>>>
>>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>>> >> sthorger at redhat.com>
>>> >>>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <
>>> psilva at redhat.com>
>>> >>>>>>>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>>> >> sthorger at redhat.com>
>>> >>>>>>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <
>>> psilva at redhat.com>
>>> >>>>>>>>>> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>> >>>>>>>>>>> sthorger at redhat.com> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>> Is it this stuff you're thinking about:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>
>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>> >>>>>>>>>>>>   From that it does a get including the ticket as a query
>>> >> parameter.
>>> >>>>>>>>>>>> I don't like the idea of sending tickets as query params as
>>> >> they could be
>>> >>>>>>>>>>>> logged. For the application initiated action it would have
>>> to
>>> >> be an ID
>>> >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps
>>> we
>>> >> have a way of
>>> >>>>>>>>>>>> creating a ticket that can only be used to initiate an
>>> action.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>> Why you need to send the id token if the client already got
>>> an id
>>> >>>>>>>>>>> token and, considering browser flow, there is a cookie that
>>> can
>>> >> be used by
>>> >>>>>>>>>>> Keycloak to identify the client/user ?
>>> >>>>>>>>>>>
>>> >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>> >>>>>>>>>>
>>> >>>>>>>>> But the identity cookie has the user session and from it we can
>>> >> check
>>> >>>>>>>>> whether or not the client initiating the action (client_id)
>>> has a
>>> >>>>>>>>> authenticated client session, no ?
>>> >>>>>>>>>
>>> >>>>>>>> That only proves that the client_id belongs to a client that has
>>> >>>>>>>> obtained a token. It doesn't authenticate the client in any way.
>>> >>>>>>>>
>>> >>>>>>>> Q- Why is authentication of the client required? IMO it is not
>>> >>>>>>>> required.
>>> >>>>>>>>
>>> >>>>>>> Sure, but the client obtained token and is authenticated, thus
>>> acting
>>> >>>>>>> on behalf of the user. If the client is already acting on behalf
>>> of
>>> >> a user,
>>> >>>>>>> we don't need to authenticate it.
>>> >>>>>>>
>>> >>>>>> That's not correct. All we know is that a client with the same
>>> >> client_id
>>> >>>>>> has obtained a token. Anyone can use the same client_id to
>>> initiate an
>>> >>>>>> action.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>>>>>>> Perhaps what we could do is:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> 1. By default any application can initiate an action
>>> >>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of
>>> any
>>> >>>>>>>>>>>> sort, just a regular oauth flow
>>> >>>>>>>>>>>> 2. Later add support if demand to limit what applications
>>> can
>>> >>>>>>>>>>>> initiate actions
>>> >>>>>>>>>>>> 2.1 Same as before if the action being initiated is open for
>>> >>>>>>>>>>>> everyone then no need for a ticket
>>> >>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>> >>>>>>>>>>>> applications we would need some form of authentication.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA
>>> claim
>>> >>>>>>>>>>>> redirect does
>>> >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>>> >> endpoint
>>> >>>>>>>>>>>> using an id token as bearer token
>>> >>>>>>>>>>>> c. Add a note into client session with a initiate action
>>> ticket
>>> >>>>>>>>>>>> for clients that can initiate actions and map this into the
>>> id
>>> >> token.
>>> >>>>>>>>>>> Not sure ...
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> If you think about it, the part interested in obtaining the
>>> >> claims
>>> >>>>>>>>>>> after an action is completed is not the client but the
>>> audience
>>> >> of the
>>> >>>>>>>>>>> token, the resource server. In this case, the UMA approach
>>> seems
>>> >> more
>>> >>>>>>>>>>> appropriate because the resource server is in control about
>>> what
>>> >> actions
>>> >>>>>>>>>>> the client should initiate in order to fulfill the
>>> constraints
>>> >> imposed by
>>> >>>>>>>>>>> the resource server to access its protected resources. Where
>>> >> these
>>> >>>>>>>>>>> constraints could be a DOB in the token or a higher security
>>> >> level.
>>> >>>>>>>>>>> The app initiating actions in the server is not the goal,
>>> but the
>>> >>>>>>>>>>> tool to obtain additional claims from the server ...
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> However, for some applications acting as both client and
>>> resource
>>> >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket
>>> dance
>>> >> and just
>>> >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>> >>>>>>>>>>>
>>> >>>>>>>>>> Perhaps there's a case for that, but that would be claims
>>> >> gathering,
>>> >>>>>>>>>> not application initiated actions.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Application initiated actions are more a tool for folks to add
>>> >>>>>>>>>> actions for the user account into their own GUIs, and as such
>>> >> should be a
>>> >>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
>>> >> have any
>>> >>>>>>>>>> flows between app and service, but rather just allows the app
>>> to
>>> >> get the
>>> >>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>> >>>>>>>>>>
>>> >>>>>>>>> I think claims gathering and AIA are pretty much the same
>>> thing.
>>> >> Both
>>> >>>>>>>>> are querying the user for additional information. Despite if
>>> you
>>> >> are
>>> >>>>>>>>> initiating an action to request user's DOB or update a
>>> password,
>>> >> they are
>>> >>>>>>>>> steps that the user must perform in order to enrich its
>>> security
>>> >> context
>>> >>>>>>>>> and be able to continue using both client and resource server.
>>> >>>>>>>>>
>>> >>>>>>>>> The point I'm trying to make is that AIA can solve other
>>> problems
>>> >>>>>>>>> too. You would still solve the original problem from your
>>> design
>>> >> document
>>> >>>>>>>>> as defined in the motivation section. While you would also help
>>> >> with
>>> >>>>>>>>> step-up authentication and UMA claims gathering. Another point
>>> is
>>> >> related
>>> >>>>>>>>> to the party interested in the action. Is it the client or the
>>> >> resource
>>> >>>>>>>>> server (the API)?
>>> >>>>>>>>>
>>> >>>>>>>>> If the client (which honestly I don't see much use as most apps
>>> >> seem
>>> >>>>>>>>> to be a combination of front-end + back-end, where the
>>> >> functionality is
>>> >>>>>>>>> provided by the back-end and protected by a bearer token) then
>>> you
>>> >> may just
>>> >>>>>>>>> consider passing the "kc_action" parameter and have the action
>>> >> initiated.
>>> >>>>>>>>> If the resource server, you could associate the required
>>> actions
>>> >> with
>>> >>>>>>>>> the scopes. So when a client requests a specific scope,
>>> Keycloak
>>> >> will start
>>> >>>>>>>>> the action(s) and query the user for some information prior to
>>> >> issuing the
>>> >>>>>>>>> access token.
>>> >>>>>>>>>
>>> >>>>>>>>> Still, if the resource server, the resource server could
>>> respond to
>>> >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
>>> >> then the
>>> >>>>>>>>> client will just redirect the user to the location provided in
>>> the
>>> >> response
>>> >>>>>>>>> to initiate the actions.
>>> >>>>>>>>>
>>> >>>>>>>> I don't understand what your point is or what you are proposing
>>> >> here.
>>> >>>>>>> And I do understand your point of view. I just think that it can
>>> do
>>> >>>>>>> much more than address new account management console
>>> requirements.
>>> >>>>>>>
>>> >>>>>>> Based on your design document, I understand what you described
>>> in the
>>> >>>>>>> Motivation section. But again, instead of considering the "two
>>> >> things" that
>>> >>>>>>> originated the idea behind AIA, I think we can take the
>>> opportunity
>>> >> and do
>>> >>>>>>> much more. As they seem related to me. Especially after your DOB
>>> >> example.
>>> >>>>>> I don't see the additional use-cases you are mentioning as
>>> related at
>>> >>>>>> all.
>>> >>>>>>
>>> >>>>> How it is not related ? The audience of the information gathered
>>> during
>>> >>>>> the AIA does impact where the token with the information will be
>>> used.
>>> >> If I
>>> >>>>> need a DOB to access some page in my front-end, this is one thing.
>>> If I
>>> >>>>> need DOB to access some resource protected by a resource server it
>>> is
>>> >>>>> another thing. Both require tokens with different audiences, the
>>> former
>>> >>>>> will probably be an ID Token where the latter the access token.
>>> >>>>>
>>> >>>>> In OAuth2 the scopes represent the permissions to access protected
>>> >>>>> resources. Thus, it does make sense to have required actions that
>>> can
>>> >>>>> challenge a user when requesting scopes. Considering your DOB
>>> example,
>>> >> if
>>> >>>>> my client wants to access resource /api/age/check why you want the
>>> >> client
>>> >>>>> to request kc_action=dob if the scope "dob" is what he needs to
>>> access
>>> >> the
>>> >>>>> API ? Otherwise, you are making the client aware of things that are
>>> >> really
>>> >>>>> related to the resource server. It is OK the client ask for scope
>>> >> "age", it
>>> >>>>> is how OAuth2 authorization model works.
>>> >>>>>
>>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>>> >> client
>>> >>>>> really dumb about what it needs to access protected resources. With
>>> >> UMA,
>>> >>>>> the client will just receive a ticket and with that ticket it can
>>> >> perform
>>> >>>>> the necessary actions to make a successful authorization request
>>> to the
>>> >>>>> server.
>>> >>>>>
>>> >>>>>
>>> >>>>>> * Step-up authentication has already clear parameters in
>>> OIDC/OAuth to
>>> >>>>>> request high level of authentication. On the implementation side
>>> it's
>>> >> about
>>> >>>>>> invoking additional parts of the authentication flow, not to
>>> initiate
>>> >> an
>>> >>>>>> required action that has nothing to do with the authentication
>>> flow.
>>> >>>>>>
>>> >>>>> Can we consider a required action as a prompt for 2nd factor, for
>>> >>>>> instance ?
>>> >>>>>
>>> >>>>>
>>> >>>>>> * Claims gathering in UMA is about asking the user for additional
>>> >>>>>> claims. AIA can be used as a poor-mans workaround to lack of
>>> claims
>>> >>>>>> gathering, but end of the day it's completely different. AIA will
>>> >> allow an
>>> >>>>>> app to invoke the action update_DOB, while claims gaterhing will
>>> >> allow the
>>> >>>>>> application to request the claim DOB.
>>> >>>>>>
>>> >>>>> Not sure, if the difference is due to updating a piece of info,
>>> both
>>> >>>>> flows request the user for the info. Is just a matter of updating
>>> or
>>> >> not
>>> >>>>> updating the info.
>>> >>>>>
>>> >>>>>
>>> >>>>>> I don't see what additional things we need to consider for
>>> something
>>> >>>>>> that is in the end very simple and can be implemented in a couple
>>> >> hours
>>> >>>>>> including tests if we don't try to make it more complicated.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>> >> sthorger at redhat.com>
>>> >>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>>> >> psilva at redhat.com>
>>> >>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
>>> required?
>>> >>>>>>>>>>>>>>>>> The user will be prompted before making an action and
>>> it's
>>> >> an action they
>>> >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>>> visible/exposed to
>>> >> the client.
>>> >>>>>>>>>>>>>>>> The client is making the request and even though the
>>> user is
>>> >>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins may
>>> >> want to restrict
>>> >>>>>>>>>>>>>>>> which clients are allowed to perform such actions. That
>>> is
>>> >> what I mean by
>>> >>>>>>>>>>>>>>>> some level of authorization.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> You could even consider not authenticating the client at
>>> >> all,
>>> >>>>>>>>>>>>>>>> but still allow admins to enforce which clients should
>>> be
>>> >> allowed to
>>> >>>>>>>>>>>>>>>> initiate actions on the server.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>>> >> initiate
>>> >>>>>>>>>>>>>>> actions will work without authenticating the client.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>> >>>>>>>>>>>>>> discussing. This is more a validation of the client making
>>> >> the request.
>>> >>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
>>> >> client_id and
>>> >>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
>>> >> doing browser
>>> >>>>>>>>>>>>>> authentication the cookie is already present) and possibly
>>> >> add some level
>>> >>>>>>>>>>>>>> of authorization to enforce which clients can perform
>>> actions
>>> >> (instead of
>>> >>>>>>>>>>>>>> just relying on the authenticated session). Redirect uris
>>> are
>>> >> really
>>> >>>>>>>>>>>>>> important because you want to make sure the redirect uri
>>> is
>>> >> valid before
>>> >>>>>>>>>>>>>> redirecting the user.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>> >>>>>>>>>>>>> redirect_uris are already being checked. It's just a
>>> standard
>>> >> OAuth flow.
>>> >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>>> >> clients
>>> >>>>>>>>>>>>> can initiate actions. If that's needed then we need
>>> something
>>> >> more
>>> >>>>>>>>>>>>> complicated that properly authenticates the client, as
>>> anyone
>>> >> could just
>>> >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>>> >> application to get the
>>> >>>>>>>>>>>>> action initiated (although wouldn't then have the user
>>> >> redirected back to
>>> >>>>>>>>>>>>> the app of course).
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints
>>> like
>>> >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
>>> >> user will be
>>> >>>>>>>>>>>>>>>>>> redirected back after the action completes). But
>>> still,
>>> >> we could also add
>>> >>>>>>>>>>>>>>>>>> some level authorization.
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone
>>> can
>>> >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a
>>> different
>>> >> client.
>>> >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>>> >> happens
>>> >>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
>>> >> back to the client
>>> >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure
>>> that
>>> >> the client is
>>> >>>>>>>>>>>>>>>> known and that the user will be redirected back to a
>>> valid
>>> >> URI.
>>> >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new
>>> tokens.
>>> >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
>>> >> client wants that,
>>> >>>>>>>>>>>>>>> then they can request the user to enter a DOB, which
>>> would
>>> >> then result in
>>> >>>>>>>>>>>>>>> the DOB being available in the token.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> This flow seems very closely related with the Claims
>>> Gathering
>>> >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is
>>> there
>>> >> and see if it
>>> >>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Go for it ;)
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an endpoint
>>> >> where
>>> >>>>>>>>>>>>>>>>> the application can request a token to initate an
>>> action.
>>> >> So flow would be:
>>> >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID
>>> Token as
>>> >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>>> >> return a single use
>>> >>>>>>>>>>>>>>>>> token.
>>> >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>> >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>>> >> "?action-token=<action token>"
>>> >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId)
>>> function
>>> >> that
>>> >>>>>>>>>>>>>>>>> would get the action token before redirecting the user.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate clients
>>> and
>>> >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate
>>> actions
>>> >> may be public
>>> >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new protocol
>>> for
>>> >> this, but rather
>>> >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> So with those constraints how would you authenticate
>>> the
>>> >>>>>>>>>>>>>>>>>>> client?
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>> >>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>> >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as
>>> simple
>>> >> as leveraging authz
>>> >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>>> >> Similar to what a KC
>>> >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>> >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list on
>>> this
>>> >>>>>>>>>>>>>>>>>>>>> one.
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication of
>>> the
>>> >>>>>>>>>>>>>>>>>>>>> clients wanting to
>>> >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable
>>> about
>>> >>>>>>>>>>>>>>>>>>>>> not securing it and
>>> >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>> >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>> >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>> >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
>>> >> action
>>> >>>>>>>>>>>>>>>>>>>>> (always
>>> >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are predefined
>>> at
>>> >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>> >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
>>> mechanism.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen <
>>> >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>> >>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that are
>>> used
>>> >>>>>>>>>>>>>>>>>>>>> to prompt the user
>>> >>>>>>>>>>>>>>>>>>>>>> to
>>> >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account
>>> after
>>> >>>>>>>>>>>>>>>>>>>>> authenticating, but
>>> >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>>> >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>> >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be
>>> manually
>>> >>>>>>>>>>>>>>>>>>>>> registered with the
>>> >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>>> >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>> >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to
>>> verify
>>> >>>>>>>>>>>>>>>>>>>>> their email, but
>>> >>>>>>>>>>>>>>>>>>>>>> only
>>> >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>>> >>>>>>>>>>>>>>>>>>>>> account management
>>> >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>>> >>>>>>>>>>>>>>>>>>>>> require verifying the
>>> >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>> >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind
>>> the
>>> >>>>>>>>>>>>>>>>>>>>> scenes is just a
>>> >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>>> >>>>>>>>>>>>>>>>>>>>> application and depending on
>>> >>>>>>>>>>>>>>>>>>>>>> the
>>> >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>>> >>>>>>>>>>>>>>>>>>>>> (where the user can
>>> >>>>>>>>>>>>>>>>>>>>>> select
>>> >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>>> >>>>>>>>>>>>>>>>>>>>> application).
>>> >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform
>>> any
>>> >>>>>>>>>>>>>>>>>>>>> updates to the users
>>> >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For
>>> example
>>> >>>>>>>>>>>>>>>>>>>>> an application
>>> >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an existing
>>> >>>>>>>>>>>>>>>>>>>>> account to a social
>>> >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want
>>> to
>>> >>>>>>>>>>>>>>>>>>>>> link to the provider.
>>> >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate
>>> these I
>>> >>>>>>>>>>>>>>>>>>>>> would like to
>>> >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>>> applications
>>> >>>>>>>>>>>>>>>>>>>>> use to authenticate
>>> >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>>> >>>>>>>>>>>>>>>>>>>>> application would redirect
>>> >>>>>>>>>>>>>>>>>>>>>> to
>>> >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>>> kc_action=<action
>>> >>>>>>>>>>>>>>>>>>>>> alias> query
>>> >>>>>>>>>>>>>>>>>>>>>>> parameter.
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming
>>> all
>>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>> >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need
>>> to
>>> >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>> >>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>>> >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>> >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to
>>> use
>>> >>>>>>>>>>>>>>>>>>>>> for applications.
>>> >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the
>>> ability for
>>> >>>>>>>>>>>>>>>>>>>>> an Application
>>> >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>>> >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>> >>>>>>>>>>>>>>>>>>>>>> performing
>>> >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>>> >>>>>>>>>>>>>>>>>>>>> require the user to enter
>>> >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should
>>> not
>>> >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>> >>>>>>>>>>>>>>>>>>>>>> an
>>> >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>> >>>>>>>>>>>>>>>>>>>>>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>
>>> >> _______________________________________________
>>> >> keycloak-dev mailing list
>>> >> keycloak-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

From mposolda at redhat.com  Tue Mar 26 04:20:23 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Mar 2019 09:20:23 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAfHmt-iW6haibvbkrHPyqokaX9hVQwzMs3uUhokGirEag@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJgngAek6fKJX3MyP=X2vot4G=A=HaStaNcRYW9paHhgNe1-TQ@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<f26ca599-2d4f-ebab-daea-b900f0317b01@redhat.com>
	<CAJgngAfHmt-iW6haibvbkrHPyqokaX9hVQwzMs3uUhokGirEag@mail.gmail.com>
Message-ID: <830bcfe7-5ea9-68b5-0e7b-a730ce47ea8b@redhat.com>

On 26/03/2019 08:45, Stian Thorgersen wrote:
>
>
> On Fri, 22 Mar 2019 at 15:12, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 22/03/2019 12:42, Stian Thorgersen wrote:
>>
>>
>>     On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         I am sorry to join this so late.
>>
>>         My concern is, that in the design, it was mentioned that
>>         consent will be
>>         always required from the user. I understand that this
>>         simplifies the
>>         flow as it's more secure and not need to authenticate the
>>         client.
>>         However from the usability perspective, it doesn't look so
>>         nice to me.
>>
>>         For example assume that in the application, the user just
>>         clicked on the
>>         button "Link my account with Facebook" . Then after login
>>         with Facebook,
>>         he will see another splash screen like "Application XY wants
>>         to link
>>         your account with Facebook", which he needs to confirm. It
>>         may be
>>         especially bad for usability in this case with linking social
>>         accounts,
>>         as user may see one splash screen shown by Facebook "Application
>>         keycloak wants to access your Facebook profile and email" and
>>         then
>>         immediately another splash screen shown by Keycloak
>>         "Application Foo
>>         wants to link your account with Facebook" .
>>
>>         Maybe I am wrong, but my guess is, that our users will very
>>         quickly come
>>         with requirement "Can I ommit to show the splash screen?" .
>>         It is bit
>>         similar to the "Consent Required" switch, which I guess most
>>         people have
>>         OFF for their clients. So IMO I would rather count with this
>>         from the
>>         beginning and count with the fact, that we will need to ommit
>>         consent
>>         screen and hence verify client.
>>
>>         With regards to this, It seems that we may need also to
>>         specify if
>>         client is:
>>         - Allowed to initiate action
>>         - Allowed to initate action with the consent required
>>         - Allowed to initate action with no-consent required
>>         Maybe the "Consent required" switch can be on instead on the
>>         action
>>         itself, but the will still need to restrict if client is
>>         allowed or not
>>         to perform the action.
>>
>>
>>     I can see your point for linking to external IdP.
>>
>>     However, for everything else the actions are requesting a user to
>>     enter information before something happens. I.e. registering
>>     WebAuthn device, update password, etc.. All require the user to
>>     first fill in the form.
>     I see. But if we can think about at least of one "type" of the
>     action, which may not show any special page, there are probably
>     others :)
>>
>>         With regards to the flow, I suggest that KC will require full
>>         OIDC/OAuth2 flow. In other words, when KC redirects back to
>>         the client,
>>         the client will be required to send code-to-token request.
>>         And the
>>         action (EG. Keycloak user linked with Facebook) is done
>>         *after* the
>>         whole flow (including code-to-token flow) is finished. That
>>         should be
>>         sufficient to verify the client and at the same time, it will
>>         allow us
>>         to add some more things to tokens (EG. some facebook details)
>>         . Downside
>>         is, that it will be harder to implement though as the SPI
>>         will likely
>>         need another callback after code-to-token flow to "finish"
>>         the action...
>>
>>
>>     I don't think I understand, because if you are proposing what I'm
>>     thinking it sounds awkward. Can you list the flow?
>
>     It is pretty much OIDC flow. So:
>
>     - The initial request with "kc_action=link-facebook" is sent to
>     OIDC authentication endpoint
>     - KC (re-)authenticates user and do all the UI actions required
>     for the requested action
>     - Before the model is updated (EG.
>     userModel.addFederationLink("facebook") called), there is
>     redirection to client with code+state etc
>     - Client needs to send code-to-token request.
>     - KC will need to verify code (already done), finally finish the
>     model (EG. call "user.addFederationLink" or
>     "user.setEmailVerified(true)" ). That's where I think the SPI
>     callback will be needed. Finally re-generate tokens and verify
>     back to the application.
>     - Client receives updated tokens with all the new state (EG.
>     "email_verified" is set to true, user's birthday claim retrieved
>     from facebook is in the token etc.)
>
>     This has some good advantages like the:
>
>     - Client is verified. In case of confidential clients, there is
>     proper client authentication. For public clients, there is at
>     least redirection back to the client application and exchanging
>     for tokens, which is still bit safer than just update model on
>     server (EG. userModel.addFederationLink) and redirect to client
>     after. However for public clients, people will more likely want to
>     show the splash screen "Application XY wants to link your account"
>
>     - Tokens are updated at the end of the flow. This is important for
>     many applications though as in many cases, people will likely
>     trigger actions under some conditions. For example in the
>     application will do something like:
>
>     if (!idToken.isEmailVerified()) {
>     ??? redirectToVerifyEmailAction();
>
>     }
>
>     So without updated tokens, you will have infinite loop or the need
>     to re-trigger to OIDC flow manually again to have tokens refreshed
>     with new claims
>
> I really hate that idea ;)
>
> * You don't know the client until after the user has entered the 
> values - so invalid client would still require user to do the work, 
> but just silently revert it

If you think about this, this is the general "issue" for the OIDC flow. 
In OIDC, the client authentication is not done at the beginning of the 
flow, but at the end (code-to-token request).

In other words, if malicious client knows the clientId and redirectUri 
of some good client, nothing prevents him to start the OIDC login flow 
by construct the OIDC initial URI: 
client_id=good_client&redirect_uri=http://good.client.host&... and hence 
all the login screens will be shown to the user. But important is, that 
malicious client won't be able to finish the flow as at the end, it will 
be redirection to the redirect_uri of good client and there is client 
authentication. So malicious client don't have a way to "steal" tokens, 
which makes the attack impractical. And I think same will apply to this 
flow I propose for the Application Initiated Actions.

> * Requires special actions that somehow caches all updates
You mean that actions will need to have the state, which will be saved 
before the redirection to the client and then need to be loaded during 
the code-to-token request? I think that state is needed anyway for most 
of the actions, which are multi-screen. I don't see this as big issue.
> * May be very hard to do for some actions

Not sure I follow? I think that what I propose is almost the same as the 
flow you proposed, with the only exception, that client will be required 
to do the "code-to-token" request similarly like during OIDC flow. So 
the only added thing, will be to maintain the state.

Marek

>
> I could go on
>
>>
>>         Last thing, I was thinking about using "scope" parameter to
>>         reference
>>         those actions instead of have proprietary "kc_action" thing.
>>         The we
>>         don't need any extensions of OIDC. It may simplify things
>>         like consents
>>         etc. Also client will be able to have something similar like
>>         we have in
>>         "Client Scopes" tab - the list of action, which he is allowed to
>>         initiate. But I am not sure about this last point and maybe
>>         it's better
>>         to keep things separated...
>>
>>
>>     I'm not convinced using scope param makes sense. It just doesn't
>>     fit in my mental model.
>
>     I see. I am also not convinced so much about scope param... Just
>     some quick idea :)
>
>     Marek
>
>>
>>         Marek
>>
>>
>>
>>
>>         On 21/03/2019 14:07, Pedro Igor Silva wrote:
>>         > Sure, I'm not against the initial design/scope. Just tried
>>         to make comments
>>         > about other aspects that, to me, are related or how it can
>>         be leveraged to
>>         > also achieve other things.
>>         >
>>         > So, what Stian plans mentioned in one of his replies is
>>         fine for me.
>>         >
>>         > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>         >
>>         >> Pedro,
>>         >>
>>         >> My only concern is getting this nailed down so we can move
>>         forward with
>>         >> the new account console.
>>         >>
>>         >> It sounds like Stian's proposal is simpler, but covers
>>         fewer use cases.
>>         >> Is that correct?
>>         >>
>>         >> Would it be practical to implement Stian's plan and then
>>         implement your
>>         >> proposal at a later date?
>>         >>
>>         >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>         >>> In addition to everything you said.
>>         >>>
>>         >>> * It is not only about making changes to account, but
>>         updating tokens
>>         >> with
>>         >>> information from required actions, which not necessarily
>>         need to be
>>         >>> persisted.
>>         >>>
>>         >>> * For back-end applications, we could also associate
>>         these required
>>         >> actions
>>         >>> with scopes. If we could have a required action as
>>         "Re-authenticate" or
>>         >>> "Provide 2nd factor", that would also help with step-up
>>         authentication.
>>         >> As
>>         >>> an alternative to OIDC acr related parameters/claims. I
>>         don't think it
>>         >>> makes sense to bring to the client concerns that are
>>         really tied to the
>>         >>> scopes of a resource server. As I said, clients should
>>         ask for scopes and
>>         >>> Keycloak should do whatever is necessary to grant these
>>         (via consent, via
>>         >>> additional steps/actions). Consider what you mentioned at
>>         the end of your
>>         >>> design document at "Require Re-Authentication". Couldn't
>>         we leverage AIA
>>         >>> for step-up and ask the user for a more stronger credential ?
>>         >>>
>>         >>> * Claims gathering flow is simple. The Keycloak server
>>         would return the
>>         >>> endpoint to where the client should redirect the user.
>>         After obtaining
>>         >>> information from the user, Keycloak would issue a ticket
>>         (instead of
>>         >> code).
>>         >>> The endpoint returned by Keycloak would contain the
>>         action associated
>>         >> with
>>         >>> a resource. The endpoint could be the same as what you
>>         are using for AIA.
>>         >>>
>>         >>>
>>         >>>
>>         >>>
>>         >>>
>>         >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         >>> wrote:
>>         >>>
>>         >>>> Pedro,
>>         >>>>
>>         >>>> I really don't understand what your points are and what
>>         you propose we
>>         >> do
>>         >>>> here.
>>         >>>>
>>         >>>> The use-case we're addressing is the following:
>>         >>>>
>>         >>>> As a user I would like to initiate an action associated
>>         with my account
>>         >>>> through a front-end application so that I can make
>>         changes to my
>>         >> account,
>>         >>>> for example to register a WebAuthn security key with my
>>         account.
>>         >>>>
>>         >>>> Further, we want an action to be implemented once and
>>         re-usable in
>>         >>>> login/registration flows as well as from applications
>>         managing user
>>         >>>> accounts, incuding our new account console. That means
>>         our new account
>>         >>>> console needs to be able to invoke an action in the
>>         login flow,
>>         >> otherwise
>>         >>>> we would have to implement actions as react/rest also.
>>         >>>>
>>         >>>> Now the solution I have proposed is simple. It allows an
>>         application to
>>         >>>> request an action being invoked after the user has
>>         authenticated. Think
>>         >> of
>>         >>>> it as a "required action" on-demand. It can be
>>         implemented with a few
>>         >> lines
>>         >>>> of code and easily tested. It is very easy to use as it
>>         just means
>>         >> adding
>>         >>>> an extra query param to the login flows, which makes it
>>         very easy to use
>>         >>>> both for confidential and non-confidential clients.
>>         >>>>
>>         >>>> It is not trying to cover claims gathering use-case from
>>         UMA. I see no
>>         >>>> connection to this and step-up authentication. These
>>         both already have
>>         >>>> clearly defined protocols. Neither can be used to
>>         address the above
>>         >>>> use-case.
>>         >>>>
>>         >>>> So please come with a concrete proposal as I have no
>>         clue what your
>>         >>>> objections are.
>>         >>>>
>>         >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
>>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>>         >> wrote:
>>         >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen
>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         >>>>> wrote:
>>         >>>>>
>>         >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva
>>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>>         >>>>>> wrote:
>>         >>>>>>
>>         >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         >>>>>>> wrote:
>>         >>>>>>>
>>         >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
>>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>>         >>>>>>>> wrote:
>>         >>>>>>>>
>>         >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         >>>>>>>>> wrote:
>>         >>>>>>>>>
>>         >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva
>>         <psilva at redhat.com <mailto:psilva at redhat.com>>
>>         >>>>>>>>>> wrote:
>>         >>>>>>>>>>
>>         >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>         >>>>>>>>>>> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         wrote:
>>         >>>>>>>>>>>
>>         >>>>>>>>>>>> Is it this stuff you're thinking about:
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>>>
>>         >>
>>         https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>         >>>>>>>>>>>> ?From that it does a get including the ticket as
>>         a query
>>         >> parameter.
>>         >>>>>>>>>>>> I don't like the idea of sending tickets as
>>         query params as
>>         >> they could be
>>         >>>>>>>>>>>> logged. For the application initiated action it
>>         would have to
>>         >> be an ID
>>         >>>>>>>>>>>> token sent as the ticket. Or as I mentioned
>>         before perhaps we
>>         >> have a way of
>>         >>>>>>>>>>>> creating a ticket that can only be used to
>>         initiate an action.
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>> Why you need to send the id token if the client
>>         already got an id
>>         >>>>>>>>>>> token and, considering browser flow, there is a
>>         cookie that can
>>         >> be used by
>>         >>>>>>>>>>> Keycloak to identify the client/user ?
>>         >>>>>>>>>>>
>>         >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>         >>>>>>>>>>
>>         >>>>>>>>> But the identity cookie has the user session and
>>         from it we can
>>         >> check
>>         >>>>>>>>> whether or not the client initiating the action
>>         (client_id) has a
>>         >>>>>>>>> authenticated client session, no ?
>>         >>>>>>>>>
>>         >>>>>>>> That only proves that the client_id belongs to a
>>         client that has
>>         >>>>>>>> obtained a token. It doesn't authenticate the client
>>         in any way.
>>         >>>>>>>>
>>         >>>>>>>> Q- Why is authentication of the client required? IMO
>>         it is not
>>         >>>>>>>> required.
>>         >>>>>>>>
>>         >>>>>>> Sure, but the client obtained token and is
>>         authenticated, thus acting
>>         >>>>>>> on behalf of the user. If the client is already
>>         acting on behalf of
>>         >> a user,
>>         >>>>>>> we don't need to authenticate it.
>>         >>>>>>>
>>         >>>>>> That's not correct. All we know is that a client with
>>         the same
>>         >> client_id
>>         >>>>>> has obtained a token. Anyone can use the same
>>         client_id to initiate an
>>         >>>>>> action.
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>>>>>>> Perhaps what we could do is:
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>>> 1. By default any application can initiate an action
>>         >>>>>>>>>>>> 1.1. To initiate an action there's no need for a
>>         ticket of any
>>         >>>>>>>>>>>> sort, just a regular oauth flow
>>         >>>>>>>>>>>> 2. Later add support if demand to limit what
>>         applications can
>>         >>>>>>>>>>>> initiate actions
>>         >>>>>>>>>>>> 2.1 Same as before if the action being initiated
>>         is open for
>>         >>>>>>>>>>>> everyone then no need for a ticket
>>         >>>>>>>>>>>> 2.2 If the action being initiated is only
>>         permitted by some
>>         >>>>>>>>>>>> applications we would need some form of
>>         authentication.
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>>> a. Just include id_token as a ticket query param
>>         like? UMA claim
>>         >>>>>>>>>>>> redirect does
>>         >>>>>>>>>>>> b. Add support to obtain an initiate action
>>         ticket from a
>>         >> endpoint
>>         >>>>>>>>>>>> using an id token as bearer token
>>         >>>>>>>>>>>> c. Add a note into client session with a
>>         initiate action ticket
>>         >>>>>>>>>>>> for clients that can initiate actions and map
>>         this into the id
>>         >> token.
>>         >>>>>>>>>>> Not sure ...
>>         >>>>>>>>>>>
>>         >>>>>>>>>>> If you think about it, the part interested in
>>         obtaining the
>>         >> claims
>>         >>>>>>>>>>> after an action is completed is not the client
>>         but the audience
>>         >> of the
>>         >>>>>>>>>>> token, the resource server. In this case, the UMA
>>         approach seems
>>         >> more
>>         >>>>>>>>>>> appropriate because the resource server is in
>>         control about what
>>         >> actions
>>         >>>>>>>>>>> the client should initiate in order to fulfill
>>         the constraints
>>         >> imposed by
>>         >>>>>>>>>>> the resource server to access its protected
>>         resources. Where
>>         >> these
>>         >>>>>>>>>>> constraints could be a DOB in the token or a
>>         higher security
>>         >> level.
>>         >>>>>>>>>>> The app initiating actions in the server is not
>>         the goal, but the
>>         >>>>>>>>>>> tool to obtain additional claims from the server ...
>>         >>>>>>>>>>>
>>         >>>>>>>>>>> However, for some applications acting as both
>>         client and resource
>>         >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the
>>         ticket dance
>>         >> and just
>>         >>>>>>>>>>> redirect the user to the server as you pointed
>>         out in 1.
>>         >>>>>>>>>>>
>>         >>>>>>>>>> Perhaps there's a case for that, but that would be
>>         claims
>>         >> gathering,
>>         >>>>>>>>>> not application initiated actions.
>>         >>>>>>>>>>
>>         >>>>>>>>>> Application initiated actions are more a tool for
>>         folks to add
>>         >>>>>>>>>> actions for the user account into their own GUIs,
>>         and as such
>>         >> should be a
>>         >>>>>>>>>> simple protocol. OAuth incremental scopes for
>>         example doesn't
>>         >> have any
>>         >>>>>>>>>> flows between app and service, but rather just
>>         allows the app to
>>         >> get the
>>         >>>>>>>>>> scopes it out of bounds knows it needs for
>>         specific actions.
>>         >>>>>>>>>>
>>         >>>>>>>>> I think claims gathering and AIA are pretty much
>>         the same thing.
>>         >> Both
>>         >>>>>>>>> are querying the user for additional information.
>>         Despite if you
>>         >> are
>>         >>>>>>>>> initiating an action to request user's DOB or
>>         update a password,
>>         >> they are
>>         >>>>>>>>> steps that the user must perform in order to enrich
>>         its security
>>         >> context
>>         >>>>>>>>> and be able to continue using both client and
>>         resource server.
>>         >>>>>>>>>
>>         >>>>>>>>> The point I'm trying to make is that AIA can solve
>>         other problems
>>         >>>>>>>>> too. You would still solve the original problem
>>         from your design
>>         >> document
>>         >>>>>>>>> as defined in the motivation section. While you
>>         would also help
>>         >> with
>>         >>>>>>>>> step-up authentication and UMA claims gathering.
>>         Another point is
>>         >> related
>>         >>>>>>>>> to the party interested in the action. Is it the
>>         client or the
>>         >> resource
>>         >>>>>>>>> server (the API)?
>>         >>>>>>>>>
>>         >>>>>>>>> If the client (which honestly I don't see much use
>>         as most apps
>>         >> seem
>>         >>>>>>>>> to be a combination of front-end + back-end, where the
>>         >> functionality is
>>         >>>>>>>>> provided by the back-end and protected by a bearer
>>         token) then you
>>         >> may just
>>         >>>>>>>>> consider passing the "kc_action" parameter and have
>>         the action
>>         >> initiated.
>>         >>>>>>>>> If the resource server, you could associate the
>>         required actions
>>         >> with
>>         >>>>>>>>> the scopes. So when a client requests a specific
>>         scope, Keycloak
>>         >> will start
>>         >>>>>>>>> the action(s) and query the user for some
>>         information prior to
>>         >> issuing the
>>         >>>>>>>>> access token.
>>         >>>>>>>>>
>>         >>>>>>>>> Still, if the resource server, the resource server
>>         could respond to
>>         >>>>>>>>> the client (e.g: UMA flow) indicating that it needs
>>         more info,
>>         >> then the
>>         >>>>>>>>> client will just redirect the user to the location
>>         provided in the
>>         >> response
>>         >>>>>>>>> to initiate the actions.
>>         >>>>>>>>>
>>         >>>>>>>> I don't understand what your point is or what you
>>         are proposing
>>         >> here.
>>         >>>>>>> And I do understand your point of view. I just think
>>         that it can do
>>         >>>>>>> much more than address new account management console
>>         requirements.
>>         >>>>>>>
>>         >>>>>>> Based on your design document, I understand what you
>>         described in the
>>         >>>>>>> Motivation section. But again, instead of considering
>>         the "two
>>         >> things" that
>>         >>>>>>> originated the idea behind AIA, I think we can take
>>         the opportunity
>>         >> and do
>>         >>>>>>> much more. As they seem related to me. Especially
>>         after your DOB
>>         >> example.
>>         >>>>>> I don't see the additional use-cases you are
>>         mentioning as related at
>>         >>>>>> all.
>>         >>>>>>
>>         >>>>> How it is not related ? The audience of the information
>>         gathered during
>>         >>>>> the AIA does impact where the token with the
>>         information will be used.
>>         >> If I
>>         >>>>> need a DOB to access some page in my front-end, this is
>>         one thing. If I
>>         >>>>> need DOB to access some resource protected by a
>>         resource server it is
>>         >>>>> another thing. Both require tokens with different
>>         audiences, the former
>>         >>>>> will probably be an ID Token where the latter the
>>         access token.
>>         >>>>>
>>         >>>>> In OAuth2 the scopes represent the permissions to
>>         access protected
>>         >>>>> resources. Thus, it does make sense to have required
>>         actions that can
>>         >>>>> challenge a user when requesting scopes. Considering
>>         your DOB example,
>>         >> if
>>         >>>>> my client wants to access resource /api/age/check why
>>         you want the
>>         >> client
>>         >>>>> to request kc_action=dob if the scope "dob" is what he
>>         needs to access
>>         >> the
>>         >>>>> API ? Otherwise, you are making the client aware of
>>         things that are
>>         >> really
>>         >>>>> related to the resource server. It is OK the client ask
>>         for scope
>>         >> "age", it
>>         >>>>> is how OAuth2 authorization model works.
>>         >>>>>
>>         >>>>> UMA leverages OAuth2 in a way that the permission
>>         ticket makes the
>>         >> client
>>         >>>>> really dumb about what it needs to access protected
>>         resources. With
>>         >> UMA,
>>         >>>>> the client will just receive a ticket and with that
>>         ticket it can
>>         >> perform
>>         >>>>> the necessary actions to make a successful
>>         authorization request to the
>>         >>>>> server.
>>         >>>>>
>>         >>>>>
>>         >>>>>> * Step-up authentication has already clear parameters
>>         in OIDC/OAuth to
>>         >>>>>> request high level of authentication. On the
>>         implementation side it's
>>         >> about
>>         >>>>>> invoking additional parts of the authentication flow,
>>         not to initiate
>>         >> an
>>         >>>>>> required action that has nothing to do with the
>>         authentication flow.
>>         >>>>>>
>>         >>>>> Can we consider a required action as a prompt for 2nd
>>         factor, for
>>         >>>>> instance ?
>>         >>>>>
>>         >>>>>
>>         >>>>>> * Claims gathering in UMA is about asking the user for
>>         additional
>>         >>>>>> claims. AIA can be used as a poor-mans workaround to
>>         lack of claims
>>         >>>>>> gathering, but end of the day it's completely
>>         different. AIA will
>>         >> allow an
>>         >>>>>> app to invoke the action update_DOB, while claims
>>         gaterhing will
>>         >> allow the
>>         >>>>>> application to request the claim DOB.
>>         >>>>>>
>>         >>>>> Not sure, if the difference is due to updating a piece
>>         of info, both
>>         >>>>> flows request the user for the info. Is just a matter
>>         of updating or
>>         >> not
>>         >>>>> updating the info.
>>         >>>>>
>>         >>>>>
>>         >>>>>> I don't see what additional things we need to consider
>>         for something
>>         >>>>>> that is in the end very simple and can be implemented
>>         in a couple
>>         >> hours
>>         >>>>>> including tests if we don't try to make it more
>>         complicated.
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>         >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>         >>>>>>>>>>>> wrote:
>>         >>>>>>>>>>>>
>>         >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>>         >> psilva at redhat.com <mailto:psilva at redhat.com>>
>>         >>>>>>>>>>>>> wrote:
>>         >>>>>>>>>>>>>
>>         >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>         >>>>>>>>>>>>>> sthorger at redhat.com
>>         <mailto:sthorger at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>         >>>>>>>>>>>>>>> psilva at redhat.com <mailto:psilva at redhat.com>>
>>         wrote:
>>         >>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian
>>         Thorgersen <
>>         >>>>>>>>>>>>>>>> sthorger at redhat.com
>>         <mailto:sthorger at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>> Why do you think
>>         authentication/authorization is required?
>>         >>>>>>>>>>>>>>>>> The user will be prompted before making an
>>         action and it's
>>         >> an action they
>>         >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>>         visible/exposed to
>>         >> the client.
>>         >>>>>>>>>>>>>>>> The client is making the request and even
>>         though the user is
>>         >>>>>>>>>>>>>>>> at the Keycloak server to perform the
>>         action, admins may
>>         >> want to restrict
>>         >>>>>>>>>>>>>>>> which clients are allowed to perform such
>>         actions. That is
>>         >> what I mean by
>>         >>>>>>>>>>>>>>>> some level of authorization.
>>         >>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>> You could even consider not authenticating
>>         the client at
>>         >> all,
>>         >>>>>>>>>>>>>>>> but still allow admins to enforce which
>>         clients should be
>>         >> allowed to
>>         >>>>>>>>>>>>>>>> initiate actions on the server.
>>         >>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>> I can't see how enforcing which clients is
>>         allowed to
>>         >> initiate
>>         >>>>>>>>>>>>>>> actions will work without authenticating the
>>         client.
>>         >>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>> Maybe the word authenticate seems too much to
>>         what we are
>>         >>>>>>>>>>>>>> discussing. This is more a validation of the
>>         client making
>>         >> the request.
>>         >>>>>>>>>>>>>> Considering that, I'm saying that you could
>>         just rely on
>>         >> client_id and
>>         >>>>>>>>>>>>>> redirect uris (the client is already
>>         authenticated and if
>>         >> doing browser
>>         >>>>>>>>>>>>>> authentication the cookie is already present)
>>         and possibly
>>         >> add some level
>>         >>>>>>>>>>>>>> of authorization to enforce which clients can
>>         perform actions
>>         >> (instead of
>>         >>>>>>>>>>>>>> just relying on the authenticated session).
>>         Redirect uris are
>>         >> really
>>         >>>>>>>>>>>>>> important because you want to make sure the
>>         redirect uri is
>>         >> valid before
>>         >>>>>>>>>>>>>> redirecting the user.
>>         >>>>>>>>>>>>>>
>>         >>>>>>>>>>>>> The plan is to use the auth endpoint, so
>>         client_id and
>>         >>>>>>>>>>>>> redirect_uris are already being checked. It's
>>         just a standard
>>         >> OAuth flow.
>>         >>>>>>>>>>>>> IMO that's fine as long as there's no need to
>>         limit what
>>         >> clients
>>         >>>>>>>>>>>>> can initiate actions. If that's needed then we
>>         need something
>>         >> more
>>         >>>>>>>>>>>>> complicated that properly authenticates the
>>         client, as anyone
>>         >> could just
>>         >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>>         >> application to get the
>>         >>>>>>>>>>>>> action initiated (although wouldn't then have
>>         the user
>>         >> redirected back to
>>         >>>>>>>>>>>>> the app of course).
>>         >>>>>>>>>>>>>
>>         >>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>         >>>>>>>>>>>>>>>>> psilva at redhat.com
>>         <mailto:psilva at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>> One way is to follow authorization code
>>         constraints like
>>         >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri
>>         (assuming the
>>         >> user will be
>>         >>>>>>>>>>>>>>>>>> redirected back after the action
>>         completes). But still,
>>         >> we could also add
>>         >>>>>>>>>>>>>>>>>> some level authorization.
>>         >>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>> authorization code constraints doesn't work
>>         as anyone can
>>         >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri
>>         from a different
>>         >> client.
>>         >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask
>>         then what
>>         >> happens
>>         >>>>>>>>>>>>>>>> after the user performs an action. Is he/her
>>         redirected
>>         >> back to the client
>>         >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to
>>         make sure that
>>         >> the client is
>>         >>>>>>>>>>>>>>>> known and that the user will be redirected
>>         back to a valid
>>         >> URI.
>>         >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would
>>         get new tokens.
>>         >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the
>>         profile and the
>>         >> client wants that,
>>         >>>>>>>>>>>>>>> then they can request the user to enter a
>>         DOB, which would
>>         >> then result in
>>         >>>>>>>>>>>>>>> the DOB being available in the token.
>>         >>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>> This flow seems very closely related with the
>>         Claims Gathering
>>         >>>>>>>>>>>>>> Flow from UMA specs. We could probably review
>>         what is there
>>         >> and see if it
>>         >>>>>>>>>>>>>> can help to solve this problem of app
>>         initiated actions.
>>         >>>>>>>>>>>>>>
>>         >>>>>>>>>>>>> Go for it ;)
>>         >>>>>>>>>>>>>
>>         >>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>> Only viable option I can think of is to add
>>         an endpoint
>>         >> where
>>         >>>>>>>>>>>>>>>>> the application can request a token to
>>         initate an action.
>>         >> So flow would be:
>>         >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> }
>>         with ID Token as
>>         >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint.
>>         This would
>>         >> return a single use
>>         >>>>>>>>>>>>>>>>> token.
>>         >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as
>>         before, but
>>         >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>>         >> "?action-token=<action token>"
>>         >>>>>>>>>>>>>>>>> In the JS adapter we can add a
>>         action(actionId) function
>>         >> that
>>         >>>>>>>>>>>>>>>>> would get the action token before
>>         redirecting the user.
>>         >>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>> Not sure what you mean about level
>>         authorization.
>>         >>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian
>>         Thorgersen <
>>         >>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>         <mailto:sthorger at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>> The issue is more around how to
>>         authenticate clients and
>>         >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to
>>         initiate actions
>>         >> may be public
>>         >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a
>>         new protocol for
>>         >> this, but rather
>>         >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>         >>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>> So with those constraints how would you
>>         authenticate the
>>         >>>>>>>>>>>>>>>>>>> client?
>>         >>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor
>>         Silva <
>>         >>>>>>>>>>>>>>>>>>> psilva at redhat.com
>>         <mailto:psilva at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of
>>         authorization for
>>         >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could
>>         be as simple
>>         >> as leveraging authz
>>         >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of
>>         clients.
>>         >> Similar to what a KC
>>         >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>         >>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian
>>         Thorgersen <
>>         >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>         <mailto:sthorger at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from
>>         the list on this
>>         >>>>>>>>>>>>>>>>>>>>> one.
>>         >>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>> Especially around not having any
>>         authentication of the
>>         >>>>>>>>>>>>>>>>>>>>> clients wanting to
>>         >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable
>>         comfortable about
>>         >>>>>>>>>>>>>>>>>>>>> not securing it and
>>         >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user
>>         before doing
>>         >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>         >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>         >>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter
>>         Skopek <
>>         >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com
>>         <mailto:pskopek at redhat.com>> wrote:
>>         >>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application
>>         initiated
>>         >> action
>>         >>>>>>>>>>>>>>>>>>>>> (always
>>         >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are
>>         predefined at
>>         >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>         >>>>>>>>>>>>>>>>>>>>>> need for the client/application
>>         restriction mechanism.
>>         >>>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian
>>         Thorgersen <
>>         >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>         <mailto:sthorger at redhat.com>>
>>         >>>>>>>>>>>>>>>>>>>>>> wrote:
>>         >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required
>>         actions that are used
>>         >>>>>>>>>>>>>>>>>>>>> to prompt the user
>>         >>>>>>>>>>>>>>>>>>>>>> to
>>         >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with
>>         their account after
>>         >>>>>>>>>>>>>>>>>>>>> authenticating, but
>>         >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the
>>         application.
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP,
>>         update profile,
>>         >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>         >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have
>>         to be manually
>>         >>>>>>>>>>>>>>>>>>>>> registered with the
>>         >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be
>>         initiated by
>>         >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>         >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all
>>         users to verify
>>         >>>>>>>>>>>>>>>>>>>>> their email, but
>>         >>>>>>>>>>>>>>>>>>>>>> only
>>         >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate
>>         actions from the
>>         >>>>>>>>>>>>>>>>>>>>> account management
>>         >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email
>>         address should
>>         >>>>>>>>>>>>>>>>>>>>> require verifying the
>>         >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to
>>         introduce
>>         >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>         >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated
>>         Action behind the
>>         >>>>>>>>>>>>>>>>>>>>> scenes is just a
>>         >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated
>>         by an
>>         >>>>>>>>>>>>>>>>>>>>> application and depending on
>>         >>>>>>>>>>>>>>>>>>>>>> the
>>         >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user
>>         to complete
>>         >>>>>>>>>>>>>>>>>>>>> (where the user can
>>         >>>>>>>>>>>>>>>>>>>>>> select
>>         >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user
>>         back to the
>>         >>>>>>>>>>>>>>>>>>>>> application).
>>         >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions
>>         should perform any
>>         >>>>>>>>>>>>>>>>>>>>> updates to the users
>>         >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user
>>         first. For example
>>         >>>>>>>>>>>>>>>>>>>>> an application
>>         >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link
>>         an existing
>>         >>>>>>>>>>>>>>>>>>>>> account to a social
>>         >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if
>>         they want to
>>         >>>>>>>>>>>>>>>>>>>>> link to the provider.
>>         >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to
>>         integrate these I
>>         >>>>>>>>>>>>>>>>>>>>> would like to
>>         >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows
>>         that applications
>>         >>>>>>>>>>>>>>>>>>>>> use to authenticate
>>         >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email
>>         action the
>>         >>>>>>>>>>>>>>>>>>>>> application would redirect
>>         >>>>>>>>>>>>>>>>>>>>>> to
>>         >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>>         kc_action=<action
>>         >>>>>>>>>>>>>>>>>>>>> alias> query
>>         >>>>>>>>>>>>>>>>>>>>>>> parameter.
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now
>>         is. Assuming all
>>         >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>         >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first
>>         do we need to
>>         >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>         >>>>>>>>>>>>>>>>>>>>>>> place to restrict what
>>         clients/applications are
>>         >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>         >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it
>>         harder to use
>>         >>>>>>>>>>>>>>>>>>>>> for applications.
>>         >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is
>>         the ability for
>>         >>>>>>>>>>>>>>>>>>>>> an Application
>>         >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>>         >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>         >>>>>>>>>>>>>>>>>>>>>> performing
>>         >>>>>>>>>>>>>>>>>>>>>>> the action. For example update
>>         password should
>>         >>>>>>>>>>>>>>>>>>>>> require the user to enter
>>         >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify
>>         email should not
>>         >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>         >>>>>>>>>>>>>>>>>>>>>> an
>>         >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         _______________________________________________
>>         >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>         >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>>>>>>>>>>>>>>>>>>>>>>
>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>>>>>>>>>>>>>>>>>>>>
>>         _______________________________________________
>>         >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>         >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>>>>>>>>>>>>>>>>>>>>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>>>>>>>>>>>>>>>>>>>>
>>         >>> _______________________________________________
>>         >>> keycloak-dev mailing list
>>         >>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>
>>         >> _______________________________________________
>>         >> keycloak-dev mailing list
>>         >> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         > _______________________________________________
>>         > keycloak-dev mailing list
>>         > keycloak-dev at lists.jboss.org
>>         <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
>>
>


From mposolda at redhat.com  Tue Mar 26 04:39:28 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Mar 2019 09:39:28 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAc5mxJg5mg0pgQFO5hWu4H=QbUF5Dt_zB3enPAX5xauqg@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
	<ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>
	<CAJgngAc5mxJg5mg0pgQFO5hWu4H=QbUF5Dt_zB3enPAX5xauqg@mail.gmail.com>
Message-ID: <e961d045-9591-943f-3f2f-58d8c8142cae@redhat.com>

On 26/03/2019 08:53, Stian Thorgersen wrote:
> I'm going to remind everyone again what is the aim and scope of AIA:
>
> * It is for an application to initiate an action, period.
> * It is aimed at allowing external account console (and similar 
> applications) to make it possible for users to make changes to their 
> account where we want to delegate the logic to actions after the 
> "login flow" rather than having to duplicate the work in rest 
> endpoints as well as "login flows"
>
> That is it. The design of this feature keeps getting more and more 
> complex and we're not getting anywhere in the discussion because 
> people are suggesting nice-to-haves or hypothetical other use-cases 
> for the feature. So please keep the original use-case in mind when you 
> are commenting on this and let's not make this into a complex unusable 
> jack of all trades, but rather keep it as something simple with a 
> small narrow use-case.

I don't think that what I proposed is very complex. If I understand 
correctly, it is very similar to what you proposed with the only 
difference, that it requires client to do the whole OIDC flow including 
code-to-token request and the model is updated in the code-to-token 
request rather than before redirecting to client. It has advantages:

- Client is properly authenticated based on the known OIDC flow. Hence 
no need to mandatory display consent screen "Application XY wants you to 
do Z"
- Tokens will be available at the end of the flow with the updated state 
(EG. facebook claims or the "email_verified" claim)

Disadvantage is the more complex flow, which means that SPI will need to 
maintain state and have the additional method, which will be triggered 
at the code-to-token request. That's the only real disadvantage I see, 
but I agree that added complexity of the SPI has some price...

I don't want to block the work and hence I am not strongly enforce to 
follow my proposal :) Just wanted to propose that and it's up to you 
guys if you like it or not.

>
> On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 22/03/2019 12:49, Stian Thorgersen wrote:
>>     To authenticate the client, why don't we just
>>     require?id_token_hint to be included?
>>
>>     We would require the ID token to be issued to the client trying
>>     to initiate the action and also be associated with the current
>>     session.
>>
>>     I'd say we don't need to finely control what clients can do what
>>     at least not for now. Client should have scope on the
>>     manage_account role and that's enough for now.
>
>     This assumes that client is authenticated before action is
>     triggered. Don't we want also a possibility to trigger this
>     "Application Initiated Actions" for cases when user is not yet
>     authenticated? For example if I have web application, which will
>     be something like "Web Email client", I want to ensure that user
>     always has email verified before he is redirected to my
>     application as authenticated. So I may want to trigger OIDC flow
>     with "kc_action" even before user is authenticated.
>
> A few points here:
>
> * AIA are there to specifically run an action, not to request some 
> sort of condition on the user account. kc_action=verify_email would 
> run the verify email regardless if email is verified or not.
> * AIA are there for an application to allow a user to initiate an 
> action from within an external app. It's not really there for the app 
> to request things out of bounds.

Well, that is the question? In current Account management, we show the 
link "Link Facebook" just in case that user is not yet linked with 
Facebook. Similarly if user is already linked, we display the link 
"Unlink Facebook" . It seems to me that people will often do those 
actions based on the state of the account (EG. I want to display link 
"Verify Email" in my application, just in case that user doesn't yet 
have verified email).

Maybe I am wrong and this is not so important, we may see in the future...

Marek

>     Will be also nice for the "Terms and Conditions" actions as the
>     "Terms and Conditions" pages are often client specific, so our
>     current approach with generic "Terms and Conditions" action is
>     likely not so nice and requires that many application implements
>     some equivalent of app-specific "Terms and Conditions" page on
>     their side rather than rely on Keycloak. But with those
>     "Application Initiated Actions" we can improve on here.
>
> As far as I know we have never had a request for client specific terms 
> and conditions. Not sure that is something Keycloak should ever 
> consider, besides if we did that doesn't need kc_action, but rather 
> just some way to configure different terms based on the client.
>
>     Marek
>
>>
>>     On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>
>>
>>         On Fri, 22 Mar 2019 at 12:07, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>             I am sorry to join this so late.
>>
>>             My concern is, that in the design, it was mentioned that
>>             consent will be
>>             always required from the user. I understand that this
>>             simplifies the
>>             flow as it's more secure and not need to authenticate the
>>             client.
>>             However from the usability perspective, it doesn't look
>>             so nice to me.
>>
>>             For example assume that in the application, the user just
>>             clicked on the
>>             button "Link my account with Facebook" . Then after login
>>             with Facebook,
>>             he will see another splash screen like "Application XY
>>             wants to link
>>             your account with Facebook", which he needs to confirm.
>>             It may be
>>             especially bad for usability in this case with linking
>>             social accounts,
>>             as user may see one splash screen shown by Facebook
>>             "Application
>>             keycloak wants to access your Facebook profile and email"
>>             and then
>>             immediately another splash screen shown by Keycloak
>>             "Application Foo
>>             wants to link your account with Facebook" .
>>
>>             Maybe I am wrong, but my guess is, that our users will
>>             very quickly come
>>             with requirement "Can I ommit to show the splash screen?"
>>             . It is bit
>>             similar to the "Consent Required" switch, which I guess
>>             most people have
>>             OFF for their clients. So IMO I would rather count with
>>             this from the
>>             beginning and count with the fact, that we will need to
>>             ommit consent
>>             screen and hence verify client.
>>
>>             With regards to this, It seems that we may need also to
>>             specify if
>>             client is:
>>             - Allowed to initiate action
>>             - Allowed to initate action with the consent required
>>             - Allowed to initate action with no-consent required
>>             Maybe the "Consent required" switch can be on instead on
>>             the action
>>             itself, but the will still need to restrict if client is
>>             allowed or not
>>             to perform the action.
>>
>>
>>         I can see your point for linking to external IdP.
>>
>>         However, for everything else the actions are requesting a
>>         user to enter information before something happens. I.e.
>>         registering WebAuthn device, update password, etc.. All
>>         require the user to first fill in the form.
>>
>>
>>             With regards to the flow, I suggest that KC will require
>>             full
>>             OIDC/OAuth2 flow. In other words, when KC redirects back
>>             to the client,
>>             the client will be required to send code-to-token
>>             request. And the
>>             action (EG. Keycloak user linked with Facebook) is done
>>             *after* the
>>             whole flow (including code-to-token flow) is finished.
>>             That should be
>>             sufficient to verify the client and at the same time, it
>>             will allow us
>>             to add some more things to tokens (EG. some facebook
>>             details) . Downside
>>             is, that it will be harder to implement though as the SPI
>>             will likely
>>             need another callback after code-to-token flow to
>>             "finish" the action...
>>
>>
>>         I don't think I understand, because if you are proposing what
>>         I'm thinking it sounds awkward. Can you list the flow?
>>
>>
>>             Last thing, I was thinking about using "scope" parameter
>>             to reference
>>             those actions instead of have proprietary "kc_action"
>>             thing. The we
>>             don't need any extensions of OIDC. It may simplify things
>>             like consents
>>             etc. Also client will be able to have something similar
>>             like we have in
>>             "Client Scopes" tab - the list of action, which he is
>>             allowed to
>>             initiate. But I am not sure about this last point and
>>             maybe it's better
>>             to keep things separated...
>>
>>
>>         I'm not convinced using scope param makes sense. It just
>>         doesn't fit in my mental model.
>>
>>
>>             Marek
>>
>>
>>
>>
>>             On 21/03/2019 14:07, Pedro Igor Silva wrote:
>>             > Sure, I'm not against the initial design/scope. Just
>>             tried to make comments
>>             > about other aspects that, to me, are related or how it
>>             can be leveraged to
>>             > also achieve other things.
>>             >
>>             > So, what Stian plans mentioned in one of his replies is
>>             fine for me.
>>             >
>>             > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>             >
>>             >> Pedro,
>>             >>
>>             >> My only concern is getting this nailed down so we can
>>             move forward with
>>             >> the new account console.
>>             >>
>>             >> It sounds like Stian's proposal is simpler, but covers
>>             fewer use cases.
>>             >> Is that correct?
>>             >>
>>             >> Would it be practical to implement Stian's plan and
>>             then implement your
>>             >> proposal at a later date?
>>             >>
>>             >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>             >>> In addition to everything you said.
>>             >>>
>>             >>> * It is not only about making changes to account, but
>>             updating tokens
>>             >> with
>>             >>> information from required actions, which not
>>             necessarily need to be
>>             >>> persisted.
>>             >>>
>>             >>> * For back-end applications, we could also associate
>>             these required
>>             >> actions
>>             >>> with scopes. If we could have a required action as
>>             "Re-authenticate" or
>>             >>> "Provide 2nd factor", that would also help with
>>             step-up authentication.
>>             >> As
>>             >>> an alternative to OIDC acr related parameters/claims.
>>             I don't think it
>>             >>> makes sense to bring to the client concerns that are
>>             really tied to the
>>             >>> scopes of a resource server. As I said, clients
>>             should ask for scopes and
>>             >>> Keycloak should do whatever is necessary to grant
>>             these (via consent, via
>>             >>> additional steps/actions). Consider what you
>>             mentioned at the end of your
>>             >>> design document at "Require Re-Authentication".
>>             Couldn't we leverage AIA
>>             >>> for step-up and ask the user for a more stronger
>>             credential ?
>>             >>>
>>             >>> * Claims gathering flow is simple. The Keycloak
>>             server would return the
>>             >>> endpoint to where the client should redirect the
>>             user. After obtaining
>>             >>> information from the user, Keycloak would issue a
>>             ticket (instead of
>>             >> code).
>>             >>> The endpoint returned by Keycloak would contain the
>>             action associated
>>             >> with
>>             >>> a resource. The endpoint could be the same as what
>>             you are using for AIA.
>>             >>>
>>             >>>
>>             >>>
>>             >>>
>>             >>>
>>             >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>             >>> wrote:
>>             >>>
>>             >>>> Pedro,
>>             >>>>
>>             >>>> I really don't understand what your points are and
>>             what you propose we
>>             >> do
>>             >>>> here.
>>             >>>>
>>             >>>> The use-case we're addressing is the following:
>>             >>>>
>>             >>>> As a user I would like to initiate an action
>>             associated with my account
>>             >>>> through a front-end application so that I can make
>>             changes to my
>>             >> account,
>>             >>>> for example to register a WebAuthn security key with
>>             my account.
>>             >>>>
>>             >>>> Further, we want an action to be implemented once
>>             and re-usable in
>>             >>>> login/registration flows as well as from
>>             applications managing user
>>             >>>> accounts, incuding our new account console. That
>>             means our new account
>>             >>>> console needs to be able to invoke an action in the
>>             login flow,
>>             >> otherwise
>>             >>>> we would have to implement actions as react/rest also.
>>             >>>>
>>             >>>> Now the solution I have proposed is simple. It
>>             allows an application to
>>             >>>> request an action being invoked after the user has
>>             authenticated. Think
>>             >> of
>>             >>>> it as a "required action" on-demand. It can be
>>             implemented with a few
>>             >> lines
>>             >>>> of code and easily tested. It is very easy to use as
>>             it just means
>>             >> adding
>>             >>>> an extra query param to the login flows, which makes
>>             it very easy to use
>>             >>>> both for confidential and non-confidential clients.
>>             >>>>
>>             >>>> It is not trying to cover claims gathering use-case
>>             from UMA. I see no
>>             >>>> connection to this and step-up authentication. These
>>             both already have
>>             >>>> clearly defined protocols. Neither can be used to
>>             address the above
>>             >>>> use-case.
>>             >>>>
>>             >>>> So please come with a concrete proposal as I have no
>>             clue what your
>>             >>>> objections are.
>>             >>>>
>>             >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
>>             <psilva at redhat.com <mailto:psilva at redhat.com>>
>>             >> wrote:
>>             >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen
>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>             >>>>> wrote:
>>             >>>>>
>>             >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva
>>             <psilva at redhat.com <mailto:psilva at redhat.com>>
>>             >>>>>> wrote:
>>             >>>>>>
>>             >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>>             >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>             >>>>>>> wrote:
>>             >>>>>>>
>>             >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva
>>             <psilva at redhat.com <mailto:psilva at redhat.com>>
>>             >>>>>>>> wrote:
>>             >>>>>>>>
>>             >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>>             >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>             >>>>>>>>> wrote:
>>             >>>>>>>>>
>>             >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva
>>             <psilva at redhat.com <mailto:psilva at redhat.com>>
>>             >>>>>>>>>> wrote:
>>             >>>>>>>>>>
>>             >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian
>>             Thorgersen <
>>             >>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>> wrote:
>>             >>>>>>>>>>>
>>             >>>>>>>>>>>> Is it this stuff you're thinking about:
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>>>
>>             >>
>>             https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>             >>>>>>>>>>>>? ?From that it does a get including the
>>             ticket as a query
>>             >> parameter.
>>             >>>>>>>>>>>> I don't like the idea of sending tickets as
>>             query params as
>>             >> they could be
>>             >>>>>>>>>>>> logged. For the application initiated action
>>             it would have to
>>             >> be an ID
>>             >>>>>>>>>>>> token sent as the ticket. Or as I mentioned
>>             before perhaps we
>>             >> have a way of
>>             >>>>>>>>>>>> creating a ticket that can only be used to
>>             initiate an action.
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>> Why you need to send the id token if the
>>             client already got an id
>>             >>>>>>>>>>> token and, considering browser flow, there is
>>             a cookie that can
>>             >> be used by
>>             >>>>>>>>>>> Keycloak to identify the client/user ?
>>             >>>>>>>>>>>
>>             >>>>>>>>>> Cookie doesn't authenticate the client, only
>>             the user.
>>             >>>>>>>>>>
>>             >>>>>>>>> But the identity cookie has the user session
>>             and from it we can
>>             >> check
>>             >>>>>>>>> whether or not the client initiating the action
>>             (client_id) has a
>>             >>>>>>>>> authenticated client session, no ?
>>             >>>>>>>>>
>>             >>>>>>>> That only proves that the client_id belongs to a
>>             client that has
>>             >>>>>>>> obtained a token. It doesn't authenticate the
>>             client in any way.
>>             >>>>>>>>
>>             >>>>>>>> Q- Why is authentication of the client required?
>>             IMO it is not
>>             >>>>>>>> required.
>>             >>>>>>>>
>>             >>>>>>> Sure, but the client obtained token and is
>>             authenticated, thus acting
>>             >>>>>>> on behalf of the user. If the client is already
>>             acting on behalf of
>>             >> a user,
>>             >>>>>>> we don't need to authenticate it.
>>             >>>>>>>
>>             >>>>>> That's not correct. All we know is that a client
>>             with the same
>>             >> client_id
>>             >>>>>> has obtained a token. Anyone can use the same
>>             client_id to initiate an
>>             >>>>>> action.
>>             >>>>>>
>>             >>>>>>
>>             >>>>>>>>>>>> Perhaps what we could do is:
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>>> 1. By default any application can initiate
>>             an action
>>             >>>>>>>>>>>> 1.1. To initiate an action there's no need
>>             for a ticket of any
>>             >>>>>>>>>>>> sort, just a regular oauth flow
>>             >>>>>>>>>>>> 2. Later add support if demand to limit what
>>             applications can
>>             >>>>>>>>>>>> initiate actions
>>             >>>>>>>>>>>> 2.1 Same as before if the action being
>>             initiated is open for
>>             >>>>>>>>>>>> everyone then no need for a ticket
>>             >>>>>>>>>>>> 2.2 If the action being initiated is only
>>             permitted by some
>>             >>>>>>>>>>>> applications we would need some form of
>>             authentication.
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>>> a. Just include id_token as a ticket query
>>             param like? UMA claim
>>             >>>>>>>>>>>> redirect does
>>             >>>>>>>>>>>> b. Add support to obtain an initiate action
>>             ticket from a
>>             >> endpoint
>>             >>>>>>>>>>>> using an id token as bearer token
>>             >>>>>>>>>>>> c. Add a note into client session with a
>>             initiate action ticket
>>             >>>>>>>>>>>> for clients that can initiate actions and
>>             map this into the id
>>             >> token.
>>             >>>>>>>>>>> Not sure ...
>>             >>>>>>>>>>>
>>             >>>>>>>>>>> If you think about it, the part interested in
>>             obtaining the
>>             >> claims
>>             >>>>>>>>>>> after an action is completed is not the
>>             client but the audience
>>             >> of the
>>             >>>>>>>>>>> token, the resource server. In this case, the
>>             UMA approach seems
>>             >> more
>>             >>>>>>>>>>> appropriate because the resource server is in
>>             control about what
>>             >> actions
>>             >>>>>>>>>>> the client should initiate in order to
>>             fulfill the constraints
>>             >> imposed by
>>             >>>>>>>>>>> the resource server to access its protected
>>             resources. Where
>>             >> these
>>             >>>>>>>>>>> constraints could be a DOB in the token or a
>>             higher security
>>             >> level.
>>             >>>>>>>>>>> The app initiating actions in the server is
>>             not the goal, but the
>>             >>>>>>>>>>> tool to obtain additional claims from the
>>             server ...
>>             >>>>>>>>>>>
>>             >>>>>>>>>>> However, for some applications acting as both
>>             client and resource
>>             >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all
>>             the ticket dance
>>             >> and just
>>             >>>>>>>>>>> redirect the user to the server as you
>>             pointed out in 1.
>>             >>>>>>>>>>>
>>             >>>>>>>>>> Perhaps there's a case for that, but that
>>             would be claims
>>             >> gathering,
>>             >>>>>>>>>> not application initiated actions.
>>             >>>>>>>>>>
>>             >>>>>>>>>> Application initiated actions are more a tool
>>             for folks to add
>>             >>>>>>>>>> actions for the user account into their own
>>             GUIs, and as such
>>             >> should be a
>>             >>>>>>>>>> simple protocol. OAuth incremental scopes for
>>             example doesn't
>>             >> have any
>>             >>>>>>>>>> flows between app and service, but rather just
>>             allows the app to
>>             >> get the
>>             >>>>>>>>>> scopes it out of bounds knows it needs for
>>             specific actions.
>>             >>>>>>>>>>
>>             >>>>>>>>> I think claims gathering and AIA are pretty
>>             much the same thing.
>>             >> Both
>>             >>>>>>>>> are querying the user for additional
>>             information. Despite if you
>>             >> are
>>             >>>>>>>>> initiating an action to request user's DOB or
>>             update a password,
>>             >> they are
>>             >>>>>>>>> steps that the user must perform in order to
>>             enrich its security
>>             >> context
>>             >>>>>>>>> and be able to continue using both client and
>>             resource server.
>>             >>>>>>>>>
>>             >>>>>>>>> The point I'm trying to make is that AIA can
>>             solve other problems
>>             >>>>>>>>> too. You would still solve the original problem
>>             from your design
>>             >> document
>>             >>>>>>>>> as defined in the motivation section. While you
>>             would also help
>>             >> with
>>             >>>>>>>>> step-up authentication and UMA claims
>>             gathering. Another point is
>>             >> related
>>             >>>>>>>>> to the party interested in the action. Is it
>>             the client or the
>>             >> resource
>>             >>>>>>>>> server (the API)?
>>             >>>>>>>>>
>>             >>>>>>>>> If the client (which honestly I don't see much
>>             use as most apps
>>             >> seem
>>             >>>>>>>>> to be a combination of front-end + back-end,
>>             where the
>>             >> functionality is
>>             >>>>>>>>> provided by the back-end and protected by a
>>             bearer token) then you
>>             >> may just
>>             >>>>>>>>> consider passing the "kc_action" parameter and
>>             have the action
>>             >> initiated.
>>             >>>>>>>>> If the resource server, you could associate the
>>             required actions
>>             >> with
>>             >>>>>>>>> the scopes. So when a client requests a
>>             specific scope, Keycloak
>>             >> will start
>>             >>>>>>>>> the action(s) and query the user for some
>>             information prior to
>>             >> issuing the
>>             >>>>>>>>> access token.
>>             >>>>>>>>>
>>             >>>>>>>>> Still, if the resource server, the resource
>>             server could respond to
>>             >>>>>>>>> the client (e.g: UMA flow) indicating that it
>>             needs more info,
>>             >> then the
>>             >>>>>>>>> client will just redirect the user to the
>>             location provided in the
>>             >> response
>>             >>>>>>>>> to initiate the actions.
>>             >>>>>>>>>
>>             >>>>>>>> I don't understand what your point is or what
>>             you are proposing
>>             >> here.
>>             >>>>>>> And I do understand your point of view. I just
>>             think that it can do
>>             >>>>>>> much more than address new account management
>>             console requirements.
>>             >>>>>>>
>>             >>>>>>> Based on your design document, I understand what
>>             you described in the
>>             >>>>>>> Motivation section. But again, instead of
>>             considering the "two
>>             >> things" that
>>             >>>>>>> originated the idea behind AIA, I think we can
>>             take the opportunity
>>             >> and do
>>             >>>>>>> much more. As they seem related to me. Especially
>>             after your DOB
>>             >> example.
>>             >>>>>> I don't see the additional use-cases you are
>>             mentioning as related at
>>             >>>>>> all.
>>             >>>>>>
>>             >>>>> How it is not related ? The audience of the
>>             information gathered during
>>             >>>>> the AIA does impact where the token with the
>>             information will be used.
>>             >> If I
>>             >>>>> need a DOB to access some page in my front-end,
>>             this is one thing. If I
>>             >>>>> need DOB to access some resource protected by a
>>             resource server it is
>>             >>>>> another thing. Both require tokens with different
>>             audiences, the former
>>             >>>>> will probably be an ID Token where the latter the
>>             access token.
>>             >>>>>
>>             >>>>> In OAuth2 the scopes represent the permissions to
>>             access protected
>>             >>>>> resources. Thus, it does make sense to have
>>             required actions that can
>>             >>>>> challenge a user when requesting scopes.
>>             Considering your DOB example,
>>             >> if
>>             >>>>> my client wants to access resource /api/age/check
>>             why you want the
>>             >> client
>>             >>>>> to request kc_action=dob if the scope "dob" is what
>>             he needs to access
>>             >> the
>>             >>>>> API ? Otherwise, you are making the client aware of
>>             things that are
>>             >> really
>>             >>>>> related to the resource server. It is OK the client
>>             ask for scope
>>             >> "age", it
>>             >>>>> is how OAuth2 authorization model works.
>>             >>>>>
>>             >>>>> UMA leverages OAuth2 in a way that the permission
>>             ticket makes the
>>             >> client
>>             >>>>> really dumb about what it needs to access protected
>>             resources. With
>>             >> UMA,
>>             >>>>> the client will just receive a ticket and with that
>>             ticket it can
>>             >> perform
>>             >>>>> the necessary actions to make a successful
>>             authorization request to the
>>             >>>>> server.
>>             >>>>>
>>             >>>>>
>>             >>>>>> * Step-up authentication has already clear
>>             parameters in OIDC/OAuth to
>>             >>>>>> request high level of authentication. On the
>>             implementation side it's
>>             >> about
>>             >>>>>> invoking additional parts of the authentication
>>             flow, not to initiate
>>             >> an
>>             >>>>>> required action that has nothing to do with the
>>             authentication flow.
>>             >>>>>>
>>             >>>>> Can we consider a required action as a prompt for
>>             2nd factor, for
>>             >>>>> instance ?
>>             >>>>>
>>             >>>>>
>>             >>>>>> * Claims gathering in UMA is about asking the user
>>             for additional
>>             >>>>>> claims. AIA can be used as a poor-mans workaround
>>             to lack of claims
>>             >>>>>> gathering, but end of the day it's completely
>>             different. AIA will
>>             >> allow an
>>             >>>>>> app to invoke the action update_DOB, while claims
>>             gaterhing will
>>             >> allow the
>>             >>>>>> application to request the claim DOB.
>>             >>>>>>
>>             >>>>> Not sure, if the difference is due to updating a
>>             piece of info, both
>>             >>>>> flows request the user for the info. Is just a
>>             matter of updating or
>>             >> not
>>             >>>>> updating the info.
>>             >>>>>
>>             >>>>>
>>             >>>>>> I don't see what additional things we need to
>>             consider for something
>>             >>>>>> that is in the end very simple and can be
>>             implemented in a couple
>>             >> hours
>>             >>>>>> including tests if we don't try to make it more
>>             complicated.
>>             >>>>>>
>>             >>>>>>
>>             >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>             >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>             >>>>>>>>>>>> wrote:
>>             >>>>>>>>>>>>
>>             >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>>             >> psilva at redhat.com <mailto:psilva at redhat.com>>
>>             >>>>>>>>>>>>> wrote:
>>             >>>>>>>>>>>>>
>>             >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian
>>             Thorgersen <
>>             >>>>>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor
>>             Silva <
>>             >>>>>>>>>>>>>>> psilva at redhat.com
>>             <mailto:psilva at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian
>>             Thorgersen <
>>             >>>>>>>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>> Why do you think
>>             authentication/authorization is required?
>>             >>>>>>>>>>>>>>>>> The user will be prompted before making
>>             an action and it's
>>             >> an action they
>>             >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>>             visible/exposed to
>>             >> the client.
>>             >>>>>>>>>>>>>>>> The client is making the request and
>>             even though the user is
>>             >>>>>>>>>>>>>>>> at the Keycloak server to perform the
>>             action, admins may
>>             >> want to restrict
>>             >>>>>>>>>>>>>>>> which clients are allowed to perform
>>             such actions. That is
>>             >> what I mean by
>>             >>>>>>>>>>>>>>>> some level of authorization.
>>             >>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>> You could even consider not
>>             authenticating the client at
>>             >> all,
>>             >>>>>>>>>>>>>>>> but still allow admins to enforce which
>>             clients should be
>>             >> allowed to
>>             >>>>>>>>>>>>>>>> initiate actions on the server.
>>             >>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>> I can't see how enforcing which clients
>>             is allowed to
>>             >> initiate
>>             >>>>>>>>>>>>>>> actions will work without authenticating
>>             the client.
>>             >>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>> Maybe the word authenticate seems too much
>>             to what we are
>>             >>>>>>>>>>>>>> discussing. This is more a validation of
>>             the client making
>>             >> the request.
>>             >>>>>>>>>>>>>> Considering that, I'm saying that you
>>             could just rely on
>>             >> client_id and
>>             >>>>>>>>>>>>>> redirect uris (the client is already
>>             authenticated and if
>>             >> doing browser
>>             >>>>>>>>>>>>>> authentication the cookie is already
>>             present) and possibly
>>             >> add some level
>>             >>>>>>>>>>>>>> of authorization to enforce which clients
>>             can perform actions
>>             >> (instead of
>>             >>>>>>>>>>>>>> just relying on the authenticated
>>             session). Redirect uris are
>>             >> really
>>             >>>>>>>>>>>>>> important because you want to make sure
>>             the redirect uri is
>>             >> valid before
>>             >>>>>>>>>>>>>> redirecting the user.
>>             >>>>>>>>>>>>>>
>>             >>>>>>>>>>>>> The plan is to use the auth endpoint, so
>>             client_id and
>>             >>>>>>>>>>>>> redirect_uris are already being checked.
>>             It's just a standard
>>             >> OAuth flow.
>>             >>>>>>>>>>>>> IMO that's fine as long as there's no need
>>             to limit what
>>             >> clients
>>             >>>>>>>>>>>>> can initiate actions. If that's needed then
>>             we need something
>>             >> more
>>             >>>>>>>>>>>>> complicated that properly authenticates the
>>             client, as anyone
>>             >> could just
>>             >>>>>>>>>>>>> use the client_id and redirect_uri from a
>>             different
>>             >> application to get the
>>             >>>>>>>>>>>>> action initiated (although wouldn't then
>>             have the user
>>             >> redirected back to
>>             >>>>>>>>>>>>> the app of course).
>>             >>>>>>>>>>>>>
>>             >>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor
>>             Silva <
>>             >>>>>>>>>>>>>>>>> psilva at redhat.com
>>             <mailto:psilva at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>> One way is to follow authorization
>>             code constraints like
>>             >>>>>>>>>>>>>>>>>> checking the client_id and
>>             redirect_uri (assuming the
>>             >> user will be
>>             >>>>>>>>>>>>>>>>>> redirected back after the action
>>             completes). But still,
>>             >> we could also add
>>             >>>>>>>>>>>>>>>>>> some level authorization.
>>             >>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>> authorization code constraints doesn't
>>             work as anyone can
>>             >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri
>>             from a different
>>             >> client.
>>             >>>>>>>>>>>>>>>> I may be missing the whole flow. I would
>>             ask then what
>>             >> happens
>>             >>>>>>>>>>>>>>>> after the user performs an action. Is
>>             he/her redirected
>>             >> back to the client
>>             >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do
>>             work to make sure that
>>             >> the client is
>>             >>>>>>>>>>>>>>>> known and that the user will be
>>             redirected back to a valid
>>             >> URI.
>>             >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app
>>             would get new tokens.
>>             >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the
>>             profile and the
>>             >> client wants that,
>>             >>>>>>>>>>>>>>> then they can request the user to enter a
>>             DOB, which would
>>             >> then result in
>>             >>>>>>>>>>>>>>> the DOB being available in the token.
>>             >>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>> This flow seems very closely related with
>>             the Claims Gathering
>>             >>>>>>>>>>>>>> Flow from UMA specs. We could probably
>>             review what is there
>>             >> and see if it
>>             >>>>>>>>>>>>>> can help to solve this problem of app
>>             initiated actions.
>>             >>>>>>>>>>>>>>
>>             >>>>>>>>>>>>> Go for it ;)
>>             >>>>>>>>>>>>>
>>             >>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>> Only viable option I can think of is to
>>             add an endpoint
>>             >> where
>>             >>>>>>>>>>>>>>>>> the application can request a token to
>>             initate an action.
>>             >> So flow would be:
>>             >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id>
>>             } with ID Token as
>>             >>>>>>>>>>>>>>>>> bearer token in header to a new
>>             endpoint. This would
>>             >> return a single use
>>             >>>>>>>>>>>>>>>>> token.
>>             >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol
>>             as before, but
>>             >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>>             >> "?action-token=<action token>"
>>             >>>>>>>>>>>>>>>>> In the JS adapter we can add a
>>             action(actionId) function
>>             >> that
>>             >>>>>>>>>>>>>>>>> would get the action token before
>>             redirecting the user.
>>             >>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>> Not sure what you mean about level
>>             authorization.
>>             >>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian
>>             Thorgersen <
>>             >>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>> The issue is more around how to
>>             authenticate clients and
>>             >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to
>>             initiate actions
>>             >> may be public
>>             >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent
>>             a new protocol for
>>             >> this, but rather
>>             >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>             >>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>> So with those constraints how would
>>             you authenticate the
>>             >>>>>>>>>>>>>>>>>>> client?
>>             >>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro
>>             Igor Silva <
>>             >>>>>>>>>>>>>>>>>>> psilva at redhat.com
>>             <mailto:psilva at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of
>>             authorization for
>>             >>>>>>>>>>>>>>>>>>>> clients initiating an action. This
>>             could be as simple
>>             >> as leveraging authz
>>             >>>>>>>>>>>>>>>>>>>> in order to define white/black lists
>>             of clients.
>>             >> Similar to what a KC
>>             >>>>>>>>>>>>>>>>>>>> extension does in regards to
>>             authentication.
>>             >>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian
>>             Thorgersen <
>>             >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback
>>             from the list on this
>>             >>>>>>>>>>>>>>>>>>>>> one.
>>             >>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>> Especially around not having any
>>             authentication of the
>>             >>>>>>>>>>>>>>>>>>>>> clients wanting to
>>             >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel
>>             reasonable comfortable about
>>             >>>>>>>>>>>>>>>>>>>>> not securing it and
>>             >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the
>>             user before doing
>>             >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>             >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>             >>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter
>>             Skopek <
>>             >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com
>>             <mailto:pskopek at redhat.com>> wrote:
>>             >>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent"
>>             application initiated
>>             >> action
>>             >>>>>>>>>>>>>>>>>>>>> (always
>>             >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions
>>             are predefined at
>>             >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>             >>>>>>>>>>>>>>>>>>>>>> need for the client/application
>>             restriction mechanism.
>>             >>>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM
>>             Stian Thorgersen <
>>             >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>             <mailto:sthorger at redhat.com>>
>>             >>>>>>>>>>>>>>>>>>>>>> wrote:
>>             >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required
>>             actions that are used
>>             >>>>>>>>>>>>>>>>>>>>> to prompt the user
>>             >>>>>>>>>>>>>>>>>>>>>> to
>>             >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with
>>             their account after
>>             >>>>>>>>>>>>>>>>>>>>> authenticating, but
>>             >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the
>>             application.
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP,
>>             update profile,
>>             >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>             >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions
>>             have to be manually
>>             >>>>>>>>>>>>>>>>>>>>> registered with the
>>             >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be
>>             initiated by
>>             >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>             >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by
>>             all users to verify
>>             >>>>>>>>>>>>>>>>>>>>> their email, but
>>             >>>>>>>>>>>>>>>>>>>>>> only
>>             >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate
>>             actions from the
>>             >>>>>>>>>>>>>>>>>>>>> account management
>>             >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email
>>             address should
>>             >>>>>>>>>>>>>>>>>>>>> require verifying the
>>             >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are
>>             proposing to introduce
>>             >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>             >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated
>>             Action behind the
>>             >>>>>>>>>>>>>>>>>>>>> scenes is just a
>>             >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is
>>             initiated by an
>>             >>>>>>>>>>>>>>>>>>>>> application and depending on
>>             >>>>>>>>>>>>>>>>>>>>>> the
>>             >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the
>>             user to complete
>>             >>>>>>>>>>>>>>>>>>>>> (where the user can
>>             >>>>>>>>>>>>>>>>>>>>>> select
>>             >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the
>>             user back to the
>>             >>>>>>>>>>>>>>>>>>>>> application).
>>             >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions
>>             should perform any
>>             >>>>>>>>>>>>>>>>>>>>> updates to the users
>>             >>>>>>>>>>>>>>>>>>>>>>> account without prompting the
>>             user first. For example
>>             >>>>>>>>>>>>>>>>>>>>> an application
>>             >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to
>>             link an existing
>>             >>>>>>>>>>>>>>>>>>>>> account to a social
>>             >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user
>>             first if they want to
>>             >>>>>>>>>>>>>>>>>>>>> link to the provider.
>>             >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications
>>             to integrate these I
>>             >>>>>>>>>>>>>>>>>>>>> would like to
>>             >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows
>>             that applications
>>             >>>>>>>>>>>>>>>>>>>>> use to authenticate
>>             >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate
>>             verify-email action the
>>             >>>>>>>>>>>>>>>>>>>>> application would redirect
>>             >>>>>>>>>>>>>>>>>>>>>> to
>>             >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and
>>             add kc_action=<action
>>             >>>>>>>>>>>>>>>>>>>>> alias> query
>>             >>>>>>>>>>>>>>>>>>>>>>> parameter.
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             >>>>>>>>>>>>>>>>>>>>>>> One open question I have right
>>             now is. Assuming all
>>             >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>             >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user
>>             first do we need to
>>             >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>             >>>>>>>>>>>>>>>>>>>>>>> place to restrict what
>>             clients/applications are
>>             >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>             >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make
>>             it harder to use
>>             >>>>>>>>>>>>>>>>>>>>> for applications.
>>             >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to
>>             add is the ability for
>>             >>>>>>>>>>>>>>>>>>>>> an Application
>>             >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the
>>             user to
>>             >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>             >>>>>>>>>>>>>>>>>>>>>> performing
>>             >>>>>>>>>>>>>>>>>>>>>>> the action. For example update
>>             password should
>>             >>>>>>>>>>>>>>>>>>>>> require the user to enter
>>             >>>>>>>>>>>>>>>>>>>>>>> the current password, while
>>             verify email should not
>>             >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>             >>>>>>>>>>>>>>>>>>>>>> an
>>             >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             _______________________________________________
>>             >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>             >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             >>>>>>>>>>>>>>>>>>>>>>>
>>             >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             >>>>>>>>>>>>>>>>>>>>>
>>             _______________________________________________
>>             >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>             >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             >>>>>>>>>>>>>>>>>>>>>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             >>>>>>>>>>>>>>>>>>>>>
>>             >>> _______________________________________________
>>             >>> keycloak-dev mailing list
>>             >>> keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             >>
>>             >> _______________________________________________
>>             >> keycloak-dev mailing list
>>             >> keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             > _______________________________________________
>>             > keycloak-dev mailing list
>>             > keycloak-dev at lists.jboss.org
>>             <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
>>
>


From sthorger at redhat.com  Tue Mar 26 08:22:15 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Mar 2019 13:22:15 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <e961d045-9591-943f-3f2f-58d8c8142cae@redhat.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJrcDBd2yi03rNxb7M7RH3yaEiA+VwnShYyc0qSvn7N+d7tZDA@mail.gmail.com>
	<CAJgngAf6oxsJXRKEfW=b_0=hnbPk+1XT05XGRKoQ7sq=yB4WXQ@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
	<ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>
	<CAJgngAc5mxJg5mg0pgQFO5hWu4H=QbUF5Dt_zB3enPAX5xauqg@mail.gmail.com>
	<e961d045-9591-943f-3f2f-58d8c8142cae@redhat.com>
Message-ID: <CAJgngAdXzaQfeQQr8wpN6Bo=cRvWYt6TOdtx1O9Nqd95wApZxg@mail.gmail.com>

On Tue, 26 Mar 2019 at 09:39, Marek Posolda <mposolda at redhat.com> wrote:

> On 26/03/2019 08:53, Stian Thorgersen wrote:
>
> I'm going to remind everyone again what is the aim and scope of AIA:
>
> * It is for an application to initiate an action, period.
> * It is aimed at allowing external account console (and similar
> applications) to make it possible for users to make changes to their
> account where we want to delegate the logic to actions after the "login
> flow" rather than having to duplicate the work in rest endpoints as well as
> "login flows"
>
> That is it. The design of this feature keeps getting more and more complex
> and we're not getting anywhere in the discussion because people are
> suggesting nice-to-haves or hypothetical other use-cases for the feature.
> So please keep the original use-case in mind when you are commenting on
> this and let's not make this into a complex unusable jack of all trades,
> but rather keep it as something simple with a small narrow use-case.
>
> I don't think that what I proposed is very complex. If I understand
> correctly, it is very similar to what you proposed with the only
> difference, that it requires client to do the whole OIDC flow including
> code-to-token request and the model is updated in the code-to-token request
> rather than before redirecting to client. It has advantages:
>
> - Client is properly authenticated based on the known OIDC flow. Hence no
> need to mandatory display consent screen "Application XY wants you to do Z"
> - Tokens will be available at the end of the flow with the updated state
> (EG. facebook claims or the "email_verified" claim)
>
> Disadvantage is the more complex flow, which means that SPI will need to
> maintain state and have the additional method, which will be triggered at
> the code-to-token request. That's the only real disadvantage I see, but I
> agree that added complexity of the SPI has some price...
>
> I don't want to block the work and hence I am not strongly enforce to
> follow my proposal :) Just wanted to propose that and it's up to you guys
> if you like it or not.
>
My point is that you are complicating the flow as well as significantly
complicating the action implementations when there is no need for it to
address the use-case we are considering. id_token_hint as I suggested would
be a much simpler solution that doesn't need a "two phase" action
implementation like what you are suggesting.

>
> On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 22/03/2019 12:49, Stian Thorgersen wrote:
>>
>> To authenticate the client, why don't we just require id_token_hint to be
>> included?
>>
>> We would require the ID token to be issued to the client trying to
>> initiate the action and also be associated with the current session.
>>
>> I'd say we don't need to finely control what clients can do what at least
>> not for now. Client should have scope on the manage_account role and that's
>> enough for now.
>>
>> This assumes that client is authenticated before action is triggered.
>> Don't we want also a possibility to trigger this "Application Initiated
>> Actions" for cases when user is not yet authenticated? For example if I
>> have web application, which will be something like "Web Email client", I
>> want to ensure that user always has email verified before he is redirected
>> to my application as authenticated. So I may want to trigger OIDC flow with
>> "kc_action" even before user is authenticated.
>>
> A few points here:
>
> * AIA are there to specifically run an action, not to request some sort of
> condition on the user account. kc_action=verify_email would run the verify
> email regardless if email is verified or not.
> * AIA are there for an application to allow a user to initiate an action
> from within an external app. It's not really there for the app to request
> things out of bounds.
>
> Well, that is the question? In current Account management, we show the
> link "Link Facebook" just in case that user is not yet linked with
> Facebook. Similarly if user is already linked, we display the link "Unlink
> Facebook" . It seems to me that people will often do those actions based on
> the state of the account (EG. I want to display link "Verify Email" in my
> application, just in case that user doesn't yet have verified email).
>

Application has both the account REST API and the token available to
discover information about the user account. Through account rest it would
discover that Facebook is already linked or not. Hence, you do actually
need to be already logged-in regardless.


> Maybe I am wrong and this is not so important, we may see in the future...
>
> Marek
>
>
>
>> Will be also nice for the "Terms and Conditions" actions as the "Terms
>> and Conditions" pages are often client specific, so our current approach
>> with generic "Terms and Conditions" action is likely not so nice and
>> requires that many application implements some equivalent of app-specific
>> "Terms and Conditions" page on their side rather than rely on Keycloak. But
>> with those "Application Initiated Actions" we can improve on here.
>>
> As far as I know we have never had a request for client specific terms and
> conditions. Not sure that is something Keycloak should ever consider,
> besides if we did that doesn't need kc_action, but rather just some way to
> configure different terms based on the client.
>
>> Marek
>>
>>
>> On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, 22 Mar 2019 at 12:07, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> I am sorry to join this so late.
>>>>
>>>> My concern is, that in the design, it was mentioned that consent will
>>>> be
>>>> always required from the user. I understand that this simplifies the
>>>> flow as it's more secure and not need to authenticate the client.
>>>> However from the usability perspective, it doesn't look so nice to me.
>>>>
>>>> For example assume that in the application, the user just clicked on
>>>> the
>>>> button "Link my account with Facebook" . Then after login with
>>>> Facebook,
>>>> he will see another splash screen like "Application XY wants to link
>>>> your account with Facebook", which he needs to confirm. It may be
>>>> especially bad for usability in this case with linking social accounts,
>>>> as user may see one splash screen shown by Facebook "Application
>>>> keycloak wants to access your Facebook profile and email" and then
>>>> immediately another splash screen shown by Keycloak "Application Foo
>>>> wants to link your account with Facebook" .
>>>>
>>>> Maybe I am wrong, but my guess is, that our users will very quickly
>>>> come
>>>> with requirement "Can I ommit to show the splash screen?" . It is bit
>>>> similar to the "Consent Required" switch, which I guess most people
>>>> have
>>>> OFF for their clients. So IMO I would rather count with this from the
>>>> beginning and count with the fact, that we will need to ommit consent
>>>> screen and hence verify client.
>>>>
>>>> With regards to this, It seems that we may need also to specify if
>>>> client is:
>>>> - Allowed to initiate action
>>>> - Allowed to initate action with the consent required
>>>> - Allowed to initate action with no-consent required
>>>> Maybe the "Consent required" switch can be on instead on the action
>>>> itself, but the will still need to restrict if client is allowed or not
>>>> to perform the action.
>>>>
>>>
>>> I can see your point for linking to external IdP.
>>>
>>> However, for everything else the actions are requesting a user to enter
>>> information before something happens. I.e. registering WebAuthn device,
>>> update password, etc.. All require the user to first fill in the form.
>>>
>>>
>>>>
>>>> With regards to the flow, I suggest that KC will require full
>>>> OIDC/OAuth2 flow. In other words, when KC redirects back to the client,
>>>> the client will be required to send code-to-token request. And the
>>>> action (EG. Keycloak user linked with Facebook) is done *after* the
>>>> whole flow (including code-to-token flow) is finished. That should be
>>>> sufficient to verify the client and at the same time, it will allow us
>>>> to add some more things to tokens (EG. some facebook details) .
>>>> Downside
>>>> is, that it will be harder to implement though as the SPI will likely
>>>> need another callback after code-to-token flow to "finish" the action...
>>>>
>>>
>>> I don't think I understand, because if you are proposing what I'm
>>> thinking it sounds awkward. Can you list the flow?
>>>
>>>
>>>>
>>>> Last thing, I was thinking about using "scope" parameter to reference
>>>> those actions instead of have proprietary "kc_action" thing. The we
>>>> don't need any extensions of OIDC. It may simplify things like consents
>>>> etc. Also client will be able to have something similar like we have in
>>>> "Client Scopes" tab - the list of action, which he is allowed to
>>>> initiate. But I am not sure about this last point and maybe it's better
>>>> to keep things separated...
>>>>
>>>
>>> I'm not convinced using scope param makes sense. It just doesn't fit in
>>> my mental model.
>>>
>>>
>>>>
>>>> Marek
>>>>
>>>>
>>>>
>>>>
>>>> On 21/03/2019 14:07, Pedro Igor Silva wrote:
>>>> > Sure, I'm not against the initial design/scope. Just tried to make
>>>> comments
>>>> > about other aspects that, to me, are related or how it can be
>>>> leveraged to
>>>> > also achieve other things.
>>>> >
>>>> > So, what Stian plans mentioned in one of his replies is fine for me.
>>>> >
>>>> > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert <ssilvert at redhat.com>
>>>> wrote:
>>>> >
>>>> >> Pedro,
>>>> >>
>>>> >> My only concern is getting this nailed down so we can move forward
>>>> with
>>>> >> the new account console.
>>>> >>
>>>> >> It sounds like Stian's proposal is simpler, but covers fewer use
>>>> cases.
>>>> >> Is that correct?
>>>> >>
>>>> >> Would it be practical to implement Stian's plan and then implement
>>>> your
>>>> >> proposal at a later date?
>>>> >>
>>>> >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>>> >>> In addition to everything you said.
>>>> >>>
>>>> >>> * It is not only about making changes to account, but updating
>>>> tokens
>>>> >> with
>>>> >>> information from required actions, which not necessarily need to be
>>>> >>> persisted.
>>>> >>>
>>>> >>> * For back-end applications, we could also associate these required
>>>> >> actions
>>>> >>> with scopes. If we could have a required action as
>>>> "Re-authenticate" or
>>>> >>> "Provide 2nd factor", that would also help with step-up
>>>> authentication.
>>>> >> As
>>>> >>> an alternative to OIDC acr related parameters/claims. I don't think
>>>> it
>>>> >>> makes sense to bring to the client concerns that are really tied to
>>>> the
>>>> >>> scopes of a resource server. As I said, clients should ask for
>>>> scopes and
>>>> >>> Keycloak should do whatever is necessary to grant these (via
>>>> consent, via
>>>> >>> additional steps/actions). Consider what you mentioned at the end
>>>> of your
>>>> >>> design document at "Require Re-Authentication". Couldn't we
>>>> leverage AIA
>>>> >>> for step-up and ask the user for a more stronger credential ?
>>>> >>>
>>>> >>> * Claims gathering flow is simple. The Keycloak server would return
>>>> the
>>>> >>> endpoint to where the client should redirect the user. After
>>>> obtaining
>>>> >>> information from the user, Keycloak would issue a ticket (instead of
>>>> >> code).
>>>> >>> The endpoint returned by Keycloak would contain the action
>>>> associated
>>>> >> with
>>>> >>> a resource. The endpoint could be the same as what you are using
>>>> for AIA.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen <
>>>> sthorger at redhat.com>
>>>> >>> wrote:
>>>> >>>
>>>> >>>> Pedro,
>>>> >>>>
>>>> >>>> I really don't understand what your points are and what you
>>>> propose we
>>>> >> do
>>>> >>>> here.
>>>> >>>>
>>>> >>>> The use-case we're addressing is the following:
>>>> >>>>
>>>> >>>> As a user I would like to initiate an action associated with my
>>>> account
>>>> >>>> through a front-end application so that I can make changes to my
>>>> >> account,
>>>> >>>> for example to register a WebAuthn security key with my account.
>>>> >>>>
>>>> >>>> Further, we want an action to be implemented once and re-usable in
>>>> >>>> login/registration flows as well as from applications managing user
>>>> >>>> accounts, incuding our new account console. That means our new
>>>> account
>>>> >>>> console needs to be able to invoke an action in the login flow,
>>>> >> otherwise
>>>> >>>> we would have to implement actions as react/rest also.
>>>> >>>>
>>>> >>>> Now the solution I have proposed is simple. It allows an
>>>> application to
>>>> >>>> request an action being invoked after the user has authenticated.
>>>> Think
>>>> >> of
>>>> >>>> it as a "required action" on-demand. It can be implemented with a
>>>> few
>>>> >> lines
>>>> >>>> of code and easily tested. It is very easy to use as it just means
>>>> >> adding
>>>> >>>> an extra query param to the login flows, which makes it very easy
>>>> to use
>>>> >>>> both for confidential and non-confidential clients.
>>>> >>>>
>>>> >>>> It is not trying to cover claims gathering use-case from UMA. I
>>>> see no
>>>> >>>> connection to this and step-up authentication. These both already
>>>> have
>>>> >>>> clearly defined protocols. Neither can be used to address the above
>>>> >>>> use-case.
>>>> >>>>
>>>> >>>> So please come with a concrete proposal as I have no clue what your
>>>> >>>> objections are.
>>>> >>>>
>>>> >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva <psilva at redhat.com>
>>>> >> wrote:
>>>> >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian Thorgersen <
>>>> sthorger at redhat.com>
>>>> >>>>> wrote:
>>>> >>>>>
>>>> >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor Silva <
>>>> psilva at redhat.com>
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian Thorgersen <
>>>> >> sthorger at redhat.com>
>>>> >>>>>>> wrote:
>>>> >>>>>>>
>>>> >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor Silva <
>>>> psilva at redhat.com>
>>>> >>>>>>>> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian Thorgersen <
>>>> >> sthorger at redhat.com>
>>>> >>>>>>>>> wrote:
>>>> >>>>>>>>>
>>>> >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor Silva <
>>>> psilva at redhat.com>
>>>> >>>>>>>>>> wrote:
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian Thorgersen <
>>>> >>>>>>>>>>> sthorger at redhat.com> wrote:
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>> Is it this stuff you're thinking about:
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>
>>>> https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>> >>>>>>>>>>>>   From that it does a get including the ticket as a query
>>>> >> parameter.
>>>> >>>>>>>>>>>> I don't like the idea of sending tickets as query params as
>>>> >> they could be
>>>> >>>>>>>>>>>> logged. For the application initiated action it would have
>>>> to
>>>> >> be an ID
>>>> >>>>>>>>>>>> token sent as the ticket. Or as I mentioned before perhaps
>>>> we
>>>> >> have a way of
>>>> >>>>>>>>>>>> creating a ticket that can only be used to initiate an
>>>> action.
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>> Why you need to send the id token if the client already got
>>>> an id
>>>> >>>>>>>>>>> token and, considering browser flow, there is a cookie that
>>>> can
>>>> >> be used by
>>>> >>>>>>>>>>> Keycloak to identify the client/user ?
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>> Cookie doesn't authenticate the client, only the user.
>>>> >>>>>>>>>>
>>>> >>>>>>>>> But the identity cookie has the user session and from it we
>>>> can
>>>> >> check
>>>> >>>>>>>>> whether or not the client initiating the action (client_id)
>>>> has a
>>>> >>>>>>>>> authenticated client session, no ?
>>>> >>>>>>>>>
>>>> >>>>>>>> That only proves that the client_id belongs to a client that
>>>> has
>>>> >>>>>>>> obtained a token. It doesn't authenticate the client in any
>>>> way.
>>>> >>>>>>>>
>>>> >>>>>>>> Q- Why is authentication of the client required? IMO it is not
>>>> >>>>>>>> required.
>>>> >>>>>>>>
>>>> >>>>>>> Sure, but the client obtained token and is authenticated, thus
>>>> acting
>>>> >>>>>>> on behalf of the user. If the client is already acting on
>>>> behalf of
>>>> >> a user,
>>>> >>>>>>> we don't need to authenticate it.
>>>> >>>>>>>
>>>> >>>>>> That's not correct. All we know is that a client with the same
>>>> >> client_id
>>>> >>>>>> has obtained a token. Anyone can use the same client_id to
>>>> initiate an
>>>> >>>>>> action.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>>>>>>> Perhaps what we could do is:
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> 1. By default any application can initiate an action
>>>> >>>>>>>>>>>> 1.1. To initiate an action there's no need for a ticket of
>>>> any
>>>> >>>>>>>>>>>> sort, just a regular oauth flow
>>>> >>>>>>>>>>>> 2. Later add support if demand to limit what applications
>>>> can
>>>> >>>>>>>>>>>> initiate actions
>>>> >>>>>>>>>>>> 2.1 Same as before if the action being initiated is open
>>>> for
>>>> >>>>>>>>>>>> everyone then no need for a ticket
>>>> >>>>>>>>>>>> 2.2 If the action being initiated is only permitted by some
>>>> >>>>>>>>>>>> applications we would need some form of authentication.
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> a. Just include id_token as a ticket query param like  UMA
>>>> claim
>>>> >>>>>>>>>>>> redirect does
>>>> >>>>>>>>>>>> b. Add support to obtain an initiate action ticket from a
>>>> >> endpoint
>>>> >>>>>>>>>>>> using an id token as bearer token
>>>> >>>>>>>>>>>> c. Add a note into client session with a initiate action
>>>> ticket
>>>> >>>>>>>>>>>> for clients that can initiate actions and map this into
>>>> the id
>>>> >> token.
>>>> >>>>>>>>>>> Not sure ...
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> If you think about it, the part interested in obtaining the
>>>> >> claims
>>>> >>>>>>>>>>> after an action is completed is not the client but the
>>>> audience
>>>> >> of the
>>>> >>>>>>>>>>> token, the resource server. In this case, the UMA approach
>>>> seems
>>>> >> more
>>>> >>>>>>>>>>> appropriate because the resource server is in control about
>>>> what
>>>> >> actions
>>>> >>>>>>>>>>> the client should initiate in order to fulfill the
>>>> constraints
>>>> >> imposed by
>>>> >>>>>>>>>>> the resource server to access its protected resources. Where
>>>> >> these
>>>> >>>>>>>>>>> constraints could be a DOB in the token or a higher security
>>>> >> level.
>>>> >>>>>>>>>>> The app initiating actions in the server is not the goal,
>>>> but the
>>>> >>>>>>>>>>> tool to obtain additional claims from the server ...
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> However, for some applications acting as both client and
>>>> resource
>>>> >>>>>>>>>>> server (e.g.: a monolithic jee) can avoid all the ticket
>>>> dance
>>>> >> and just
>>>> >>>>>>>>>>> redirect the user to the server as you pointed out in 1.
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>> Perhaps there's a case for that, but that would be claims
>>>> >> gathering,
>>>> >>>>>>>>>> not application initiated actions.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Application initiated actions are more a tool for folks to
>>>> add
>>>> >>>>>>>>>> actions for the user account into their own GUIs, and as such
>>>> >> should be a
>>>> >>>>>>>>>> simple protocol. OAuth incremental scopes for example doesn't
>>>> >> have any
>>>> >>>>>>>>>> flows between app and service, but rather just allows the
>>>> app to
>>>> >> get the
>>>> >>>>>>>>>> scopes it out of bounds knows it needs for specific actions.
>>>> >>>>>>>>>>
>>>> >>>>>>>>> I think claims gathering and AIA are pretty much the same
>>>> thing.
>>>> >> Both
>>>> >>>>>>>>> are querying the user for additional information. Despite if
>>>> you
>>>> >> are
>>>> >>>>>>>>> initiating an action to request user's DOB or update a
>>>> password,
>>>> >> they are
>>>> >>>>>>>>> steps that the user must perform in order to enrich its
>>>> security
>>>> >> context
>>>> >>>>>>>>> and be able to continue using both client and resource server.
>>>> >>>>>>>>>
>>>> >>>>>>>>> The point I'm trying to make is that AIA can solve other
>>>> problems
>>>> >>>>>>>>> too. You would still solve the original problem from your
>>>> design
>>>> >> document
>>>> >>>>>>>>> as defined in the motivation section. While you would also
>>>> help
>>>> >> with
>>>> >>>>>>>>> step-up authentication and UMA claims gathering. Another
>>>> point is
>>>> >> related
>>>> >>>>>>>>> to the party interested in the action. Is it the client or the
>>>> >> resource
>>>> >>>>>>>>> server (the API)?
>>>> >>>>>>>>>
>>>> >>>>>>>>> If the client (which honestly I don't see much use as most
>>>> apps
>>>> >> seem
>>>> >>>>>>>>> to be a combination of front-end + back-end, where the
>>>> >> functionality is
>>>> >>>>>>>>> provided by the back-end and protected by a bearer token)
>>>> then you
>>>> >> may just
>>>> >>>>>>>>> consider passing the "kc_action" parameter and have the action
>>>> >> initiated.
>>>> >>>>>>>>> If the resource server, you could associate the required
>>>> actions
>>>> >> with
>>>> >>>>>>>>> the scopes. So when a client requests a specific scope,
>>>> Keycloak
>>>> >> will start
>>>> >>>>>>>>> the action(s) and query the user for some information prior to
>>>> >> issuing the
>>>> >>>>>>>>> access token.
>>>> >>>>>>>>>
>>>> >>>>>>>>> Still, if the resource server, the resource server could
>>>> respond to
>>>> >>>>>>>>> the client (e.g: UMA flow) indicating that it needs more info,
>>>> >> then the
>>>> >>>>>>>>> client will just redirect the user to the location provided
>>>> in the
>>>> >> response
>>>> >>>>>>>>> to initiate the actions.
>>>> >>>>>>>>>
>>>> >>>>>>>> I don't understand what your point is or what you are proposing
>>>> >> here.
>>>> >>>>>>> And I do understand your point of view. I just think that it
>>>> can do
>>>> >>>>>>> much more than address new account management console
>>>> requirements.
>>>> >>>>>>>
>>>> >>>>>>> Based on your design document, I understand what you described
>>>> in the
>>>> >>>>>>> Motivation section. But again, instead of considering the "two
>>>> >> things" that
>>>> >>>>>>> originated the idea behind AIA, I think we can take the
>>>> opportunity
>>>> >> and do
>>>> >>>>>>> much more. As they seem related to me. Especially after your DOB
>>>> >> example.
>>>> >>>>>> I don't see the additional use-cases you are mentioning as
>>>> related at
>>>> >>>>>> all.
>>>> >>>>>>
>>>> >>>>> How it is not related ? The audience of the information gathered
>>>> during
>>>> >>>>> the AIA does impact where the token with the information will be
>>>> used.
>>>> >> If I
>>>> >>>>> need a DOB to access some page in my front-end, this is one
>>>> thing. If I
>>>> >>>>> need DOB to access some resource protected by a resource server
>>>> it is
>>>> >>>>> another thing. Both require tokens with different audiences, the
>>>> former
>>>> >>>>> will probably be an ID Token where the latter the access token.
>>>> >>>>>
>>>> >>>>> In OAuth2 the scopes represent the permissions to access protected
>>>> >>>>> resources. Thus, it does make sense to have required actions that
>>>> can
>>>> >>>>> challenge a user when requesting scopes. Considering your DOB
>>>> example,
>>>> >> if
>>>> >>>>> my client wants to access resource /api/age/check why you want the
>>>> >> client
>>>> >>>>> to request kc_action=dob if the scope "dob" is what he needs to
>>>> access
>>>> >> the
>>>> >>>>> API ? Otherwise, you are making the client aware of things that
>>>> are
>>>> >> really
>>>> >>>>> related to the resource server. It is OK the client ask for scope
>>>> >> "age", it
>>>> >>>>> is how OAuth2 authorization model works.
>>>> >>>>>
>>>> >>>>> UMA leverages OAuth2 in a way that the permission ticket makes the
>>>> >> client
>>>> >>>>> really dumb about what it needs to access protected resources.
>>>> With
>>>> >> UMA,
>>>> >>>>> the client will just receive a ticket and with that ticket it can
>>>> >> perform
>>>> >>>>> the necessary actions to make a successful authorization request
>>>> to the
>>>> >>>>> server.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> * Step-up authentication has already clear parameters in
>>>> OIDC/OAuth to
>>>> >>>>>> request high level of authentication. On the implementation side
>>>> it's
>>>> >> about
>>>> >>>>>> invoking additional parts of the authentication flow, not to
>>>> initiate
>>>> >> an
>>>> >>>>>> required action that has nothing to do with the authentication
>>>> flow.
>>>> >>>>>>
>>>> >>>>> Can we consider a required action as a prompt for 2nd factor, for
>>>> >>>>> instance ?
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> * Claims gathering in UMA is about asking the user for additional
>>>> >>>>>> claims. AIA can be used as a poor-mans workaround to lack of
>>>> claims
>>>> >>>>>> gathering, but end of the day it's completely different. AIA will
>>>> >> allow an
>>>> >>>>>> app to invoke the action update_DOB, while claims gaterhing will
>>>> >> allow the
>>>> >>>>>> application to request the claim DOB.
>>>> >>>>>>
>>>> >>>>> Not sure, if the difference is due to updating a piece of info,
>>>> both
>>>> >>>>> flows request the user for the info. Is just a matter of updating
>>>> or
>>>> >> not
>>>> >>>>> updating the info.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> I don't see what additional things we need to consider for
>>>> something
>>>> >>>>>> that is in the end very simple and can be implemented in a couple
>>>> >> hours
>>>> >>>>>> including tests if we don't try to make it more complicated.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian Thorgersen <
>>>> >> sthorger at redhat.com>
>>>> >>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro Igor Silva <
>>>> >> psilva at redhat.com>
>>>> >>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian Thorgersen <
>>>> >>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro Igor Silva <
>>>> >>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM Stian Thorgersen <
>>>> >>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> Why do you think authentication/authorization is
>>>> required?
>>>> >>>>>>>>>>>>>>>>> The user will be prompted before making an action and
>>>> it's
>>>> >> an action they
>>>> >>>>>>>>>>>>>>>>> do against RH-SSO and not automatically
>>>> visible/exposed to
>>>> >> the client.
>>>> >>>>>>>>>>>>>>>> The client is making the request and even though the
>>>> user is
>>>> >>>>>>>>>>>>>>>> at the Keycloak server to perform the action, admins
>>>> may
>>>> >> want to restrict
>>>> >>>>>>>>>>>>>>>> which clients are allowed to perform such actions.
>>>> That is
>>>> >> what I mean by
>>>> >>>>>>>>>>>>>>>> some level of authorization.
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> You could even consider not authenticating the client
>>>> at
>>>> >> all,
>>>> >>>>>>>>>>>>>>>> but still allow admins to enforce which clients should
>>>> be
>>>> >> allowed to
>>>> >>>>>>>>>>>>>>>> initiate actions on the server.
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> I can't see how enforcing which clients is allowed to
>>>> >> initiate
>>>> >>>>>>>>>>>>>>> actions will work without authenticating the client.
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> Maybe the word authenticate seems too much to what we are
>>>> >>>>>>>>>>>>>> discussing. This is more a validation of the client
>>>> making
>>>> >> the request.
>>>> >>>>>>>>>>>>>> Considering that, I'm saying that you could just rely on
>>>> >> client_id and
>>>> >>>>>>>>>>>>>> redirect uris (the client is already authenticated and if
>>>> >> doing browser
>>>> >>>>>>>>>>>>>> authentication the cookie is already present) and
>>>> possibly
>>>> >> add some level
>>>> >>>>>>>>>>>>>> of authorization to enforce which clients can perform
>>>> actions
>>>> >> (instead of
>>>> >>>>>>>>>>>>>> just relying on the authenticated session). Redirect
>>>> uris are
>>>> >> really
>>>> >>>>>>>>>>>>>> important because you want to make sure the redirect uri
>>>> is
>>>> >> valid before
>>>> >>>>>>>>>>>>>> redirecting the user.
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> The plan is to use the auth endpoint, so client_id and
>>>> >>>>>>>>>>>>> redirect_uris are already being checked. It's just a
>>>> standard
>>>> >> OAuth flow.
>>>> >>>>>>>>>>>>> IMO that's fine as long as there's no need to limit what
>>>> >> clients
>>>> >>>>>>>>>>>>> can initiate actions. If that's needed then we need
>>>> something
>>>> >> more
>>>> >>>>>>>>>>>>> complicated that properly authenticates the client, as
>>>> anyone
>>>> >> could just
>>>> >>>>>>>>>>>>> use the client_id and redirect_uri from a different
>>>> >> application to get the
>>>> >>>>>>>>>>>>> action initiated (although wouldn't then have the user
>>>> >> redirected back to
>>>> >>>>>>>>>>>>> the app of course).
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro Igor Silva <
>>>> >>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> One way is to follow authorization code constraints
>>>> like
>>>> >>>>>>>>>>>>>>>>>> checking the client_id and redirect_uri (assuming the
>>>> >> user will be
>>>> >>>>>>>>>>>>>>>>>> redirected back after the action completes). But
>>>> still,
>>>> >> we could also add
>>>> >>>>>>>>>>>>>>>>>> some level authorization.
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> authorization code constraints doesn't work as anyone
>>>> can
>>>> >>>>>>>>>>>>>>>>> just use the client_id and redirect_uri from a
>>>> different
>>>> >> client.
>>>> >>>>>>>>>>>>>>>> I may be missing the whole flow. I would ask then what
>>>> >> happens
>>>> >>>>>>>>>>>>>>>> after the user performs an action. Is he/her redirected
>>>> >> back to the client
>>>> >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri do work to make sure
>>>> that
>>>> >> the client is
>>>> >>>>>>>>>>>>>>>> known and that the user will be redirected back to a
>>>> valid
>>>> >> URI.
>>>> >>>>>>>>>>>>>>> It's just a standard OAuth flow, so app would get new
>>>> tokens.
>>>> >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in the profile and the
>>>> >> client wants that,
>>>> >>>>>>>>>>>>>>> then they can request the user to enter a DOB, which
>>>> would
>>>> >> then result in
>>>> >>>>>>>>>>>>>>> the DOB being available in the token.
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> This flow seems very closely related with the Claims
>>>> Gathering
>>>> >>>>>>>>>>>>>> Flow from UMA specs. We could probably review what is
>>>> there
>>>> >> and see if it
>>>> >>>>>>>>>>>>>> can help to solve this problem of app initiated actions.
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Go for it ;)
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> Only viable option I can think of is to add an
>>>> endpoint
>>>> >> where
>>>> >>>>>>>>>>>>>>>>> the application can request a token to initate an
>>>> action.
>>>> >> So flow would be:
>>>> >>>>>>>>>>>>>>>>> 1. App sends POST { action: <action-id> } with ID
>>>> Token as
>>>> >>>>>>>>>>>>>>>>> bearer token in header to a new endpoint. This would
>>>> >> return a single use
>>>> >>>>>>>>>>>>>>>>> token.
>>>> >>>>>>>>>>>>>>>>> 2. App can now do the redirect protocol as before, but
>>>> >>>>>>>>>>>>>>>>> instead of "?action=<action>" they would do
>>>> >> "?action-token=<action token>"
>>>> >>>>>>>>>>>>>>>>> In the JS adapter we can add a action(actionId)
>>>> function
>>>> >> that
>>>> >>>>>>>>>>>>>>>>> would get the action token before redirecting the
>>>> user.
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> Not sure what you mean about level authorization.
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM Stian Thorgersen <
>>>> >>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> The issue is more around how to authenticate
>>>> clients and
>>>> >>>>>>>>>>>>>>>>>>> also the fact that clients wanting to initiate
>>>> actions
>>>> >> may be public
>>>> >>>>>>>>>>>>>>>>>>> clients. We also don't want to invent a new
>>>> protocol for
>>>> >> this, but rather
>>>> >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> So with those constraints how would you
>>>> authenticate the
>>>> >>>>>>>>>>>>>>>>>>> client?
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23, Pedro Igor Silva <
>>>> >>>>>>>>>>>>>>>>>>> psilva at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> IMO, we should have some level of authorization for
>>>> >>>>>>>>>>>>>>>>>>>> clients initiating an action. This could be as
>>>> simple
>>>> >> as leveraging authz
>>>> >>>>>>>>>>>>>>>>>>>> in order to define white/black lists of clients.
>>>> >> Similar to what a KC
>>>> >>>>>>>>>>>>>>>>>>>> extension does in regards to authentication.
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM Stian Thorgersen <
>>>> >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> Was hoping for some more feedback from the list
>>>> on this
>>>> >>>>>>>>>>>>>>>>>>>>> one.
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> Especially around not having any authentication
>>>> of the
>>>> >>>>>>>>>>>>>>>>>>>>> clients wanting to
>>>> >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel reasonable comfortable
>>>> about
>>>> >>>>>>>>>>>>>>>>>>>>> not securing it and
>>>> >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt the user before doing
>>>> >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>> >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07, Peter Skopek <
>>>> >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent" application initiated
>>>> >> action
>>>> >>>>>>>>>>>>>>>>>>>>> (always
>>>> >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and actions are
>>>> predefined at
>>>> >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>> >>>>>>>>>>>>>>>>>>>>>> need for the client/application restriction
>>>> mechanism.
>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23 PM Stian Thorgersen
>>>> <
>>>> >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com>
>>>> >>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has required actions that
>>>> are used
>>>> >>>>>>>>>>>>>>>>>>>>> to prompt the user
>>>> >>>>>>>>>>>>>>>>>>>>>> to
>>>> >>>>>>>>>>>>>>>>>>>>>>> perform an action associated with their account
>>>> after
>>>> >>>>>>>>>>>>>>>>>>>>> authenticating, but
>>>> >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to the application.
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure OTP, update profile,
>>>> >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>> >>>>>>>>>>>>>>>>>>>>>>> One issue here is these actions have to be
>>>> manually
>>>> >>>>>>>>>>>>>>>>>>>>> registered with the
>>>> >>>>>>>>>>>>>>>>>>>>>>> users account, but can not be initiated by
>>>> >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>> >>>>>>>>>>>>>>>>>>>>>>> example it may not be required by all users to
>>>> verify
>>>> >>>>>>>>>>>>>>>>>>>>> their email, but
>>>> >>>>>>>>>>>>>>>>>>>>>> only
>>>> >>>>>>>>>>>>>>>>>>>>>>> when they use specific applications.
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to initiate actions from the
>>>> >>>>>>>>>>>>>>>>>>>>> account management
>>>> >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating email address should
>>>> >>>>>>>>>>>>>>>>>>>>> require verifying the
>>>> >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are proposing to introduce
>>>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>> >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application Initiated Action behind
>>>> the
>>>> >>>>>>>>>>>>>>>>>>>>> scenes is just a
>>>> >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is initiated by an
>>>> >>>>>>>>>>>>>>>>>>>>> application and depending on
>>>> >>>>>>>>>>>>>>>>>>>>>> the
>>>> >>>>>>>>>>>>>>>>>>>>>>> action may be optional for the user to complete
>>>> >>>>>>>>>>>>>>>>>>>>> (where the user can
>>>> >>>>>>>>>>>>>>>>>>>>>> select
>>>> >>>>>>>>>>>>>>>>>>>>>>> cancel which would return the user back to the
>>>> >>>>>>>>>>>>>>>>>>>>> application).
>>>> >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated Actions should perform
>>>> any
>>>> >>>>>>>>>>>>>>>>>>>>> updates to the users
>>>> >>>>>>>>>>>>>>>>>>>>>>> account without prompting the user first. For
>>>> example
>>>> >>>>>>>>>>>>>>>>>>>>> an application
>>>> >>>>>>>>>>>>>>>>>>>>>>> initiated action that is used to link an
>>>> existing
>>>> >>>>>>>>>>>>>>>>>>>>> account to a social
>>>> >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user first if they want
>>>> to
>>>> >>>>>>>>>>>>>>>>>>>>> link to the provider.
>>>> >>>>>>>>>>>>>>>>>>>>>>> To make it easy for applications to integrate
>>>> these I
>>>> >>>>>>>>>>>>>>>>>>>>> would like to
>>>> >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth flows that
>>>> applications
>>>> >>>>>>>>>>>>>>>>>>>>> use to authenticate
>>>> >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate verify-email action the
>>>> >>>>>>>>>>>>>>>>>>>>> application would redirect
>>>> >>>>>>>>>>>>>>>>>>>>>> to
>>>> >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint and add
>>>> kc_action=<action
>>>> >>>>>>>>>>>>>>>>>>>>> alias> query
>>>> >>>>>>>>>>>>>>>>>>>>>>> parameter.
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> One open question I have right now is. Assuming
>>>> all
>>>> >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>> >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the user first do we need
>>>> to
>>>> >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>> >>>>>>>>>>>>>>>>>>>>>>> place to restrict what clients/applications are
>>>> >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>> >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would make it harder to
>>>> use
>>>> >>>>>>>>>>>>>>>>>>>>> for applications.
>>>> >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like to add is the
>>>> ability for
>>>> >>>>>>>>>>>>>>>>>>>>> an Application
>>>> >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require the user to
>>>> >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>> >>>>>>>>>>>>>>>>>>>>>> performing
>>>> >>>>>>>>>>>>>>>>>>>>>>> the action. For example update password should
>>>> >>>>>>>>>>>>>>>>>>>>> require the user to enter
>>>> >>>>>>>>>>>>>>>>>>>>>>> the current password, while verify email should
>>>> not
>>>> >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>> >>>>>>>>>>>>>>>>>>>>>> an
>>>> >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>> >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>> >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>> _______________________________________________
>>>> >>> keycloak-dev mailing list
>>>> >>> keycloak-dev at lists.jboss.org
>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >>
>>>> >> _______________________________________________
>>>> >> keycloak-dev mailing list
>>>> >> keycloak-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> > _______________________________________________
>>>> > keycloak-dev mailing list
>>>> > keycloak-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>

From mposolda at redhat.com  Tue Mar 26 11:38:11 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Mar 2019 16:38:11 +0100
Subject: [keycloak-dev] Application Initiated Actions
In-Reply-To: <CAJgngAdXzaQfeQQr8wpN6Bo=cRvWYt6TOdtx1O9Nqd95wApZxg@mail.gmail.com>
References: <CAJgngAeHYxNFRdAdYUJHGerDa06109O6uZWP7Aq5xQNPrW-QuA@mail.gmail.com>
	<CAJrcDBcMCGOqGDs+M769R2nbzm7HnBZK+G1h-W6RzdjmqgdyZA@mail.gmail.com>
	<CAJgngAfnQ8cNg48gD=V4oTMMJ7jqSaSKFmsuQJjAxaWJX4_M=A@mail.gmail.com>
	<CAJrcDBfa14gsHxUNLfNOF1k58C9nGds4a42fubwYiCFXWYnYQA@mail.gmail.com>
	<CAJgngAdmt9iqM48FWwxaE7zaxJ72kCa93faLp8n1oss6YMKWuw@mail.gmail.com>
	<CAJrcDBc0SyPyxfSius=h3URYWwa5QOs-7tvAn5FKywVK1SYEYA@mail.gmail.com>
	<57aeb1df-9d03-69a3-54f8-df694cd568e2@redhat.com>
	<CAJrcDBeAYKWJe_UWnYThaSrNa=HJQ4MRCqt-wq_xhu3T42T1Kw@mail.gmail.com>
	<48585137-ae01-f9ae-2ec3-174d93e679be@redhat.com>
	<CAJgngAceiaRSDXTx7VhegydUzU0UUWmC9H4Jp0LLUS7Vy5qZTQ@mail.gmail.com>
	<CAJgngAcx1pjV6ta+b2YMdoEMZJvnQMzwpKmp2sZ02hMkN+kssw@mail.gmail.com>
	<ea423e83-d114-c6ef-e241-f98d031e03f9@redhat.com>
	<CAJgngAc5mxJg5mg0pgQFO5hWu4H=QbUF5Dt_zB3enPAX5xauqg@mail.gmail.com>
	<e961d045-9591-943f-3f2f-58d8c8142cae@redhat.com>
	<CAJgngAdXzaQfeQQr8wpN6Bo=cRvWYt6TOdtx1O9Nqd95wApZxg@mail.gmail.com>
Message-ID: <97c70d1e-ffb3-2d78-17da-b54ada88fa41@redhat.com>

On 26/03/2019 13:22, Stian Thorgersen wrote:
>
>
> On Tue, 26 Mar 2019 at 09:39, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 26/03/2019 08:53, Stian Thorgersen wrote:
>>     I'm going to remind everyone again what is the aim and scope of AIA:
>>
>>     * It is for an application to initiate an action, period.
>>     * It is aimed at allowing external account console (and similar
>>     applications) to make it possible for users to make changes to
>>     their account where we want to delegate the logic to actions
>>     after the "login flow" rather than having to duplicate the work
>>     in rest endpoints as well as "login flows"
>>
>>     That is it. The design of this feature keeps getting more and
>>     more complex and we're not getting anywhere in the discussion
>>     because people are suggesting nice-to-haves or hypothetical other
>>     use-cases for the feature. So please keep the original use-case
>>     in mind when you are commenting on this and let's not make this
>>     into a complex unusable jack of all trades, but rather keep it as
>>     something simple with a small narrow use-case.
>
>     I don't think that what I proposed is very complex. If I
>     understand correctly, it is very similar to what you proposed with
>     the only difference, that it requires client to do the whole OIDC
>     flow including code-to-token request and the model is updated in
>     the code-to-token request rather than before redirecting to
>     client. It has advantages:
>
>     - Client is properly authenticated based on the known OIDC flow.
>     Hence no need to mandatory display consent screen "Application XY
>     wants you to do Z"
>     - Tokens will be available at the end of the flow with the updated
>     state (EG. facebook claims or the "email_verified" claim)
>
>     Disadvantage is the more complex flow, which means that SPI will
>     need to maintain state and have the additional method, which will
>     be triggered at the code-to-token request. That's the only real
>     disadvantage I see, but I agree that added complexity of the SPI
>     has some price...
>
>     I don't want to block the work and hence I am not strongly enforce
>     to follow my proposal :) Just wanted to propose that and it's up
>     to you guys if you like it or not.
>
> My point is that you are complicating the flow as well as 
> significantly complicating the action implementations when there is no 
> need for it to address the use-case we are considering. id_token_hint 
> as I suggested would be a much simpler solution that doesn't need a 
> "two phase" action implementation like what you are suggesting.

I don't think there is complication of the flow. It is just OIDC and our 
adapters already support it. But I agree that action implementations 
will be slightly complicated.

I have some doubts about id_token_hint. Like:

- It requires user to be already authenticated (I know you mentioned 
that this is out-of-scope and I understand it is not required for the 
account console use-case, but question is, if we want to stick AIA just 
to account console needs...).

- I also wonder about the security of passing id_token_hint in the URL? 
I know we plan to add it in the OIDC logout request too, but here it is 
probably not so bad as the session is going to be invalidated. But if 
someone intercepts the id_token_hint passed in the initial OIDC request, 
he just gained the valid ID token.

Just my 2 cents, I don't want to block the work as I joined this topic 
very late anyway :( I don't have anything against going with your 
proposal and we may see whether to change something in the future...

Marek

>>     On Fri, 22 Mar 2019 at 15:20, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 22/03/2019 12:49, Stian Thorgersen wrote:
>>>         To authenticate the client, why don't we just
>>>         require?id_token_hint to be included?
>>>
>>>         We would require the ID token to be issued to the client
>>>         trying to initiate the action and also be associated with
>>>         the current session.
>>>
>>>         I'd say we don't need to finely control what clients can do
>>>         what at least not for now. Client should have scope on the
>>>         manage_account role and that's enough for now.
>>
>>         This assumes that client is authenticated before action is
>>         triggered. Don't we want also a possibility to trigger this
>>         "Application Initiated Actions" for cases when user is not
>>         yet authenticated? For example if I have web application,
>>         which will be something like "Web Email client", I want to
>>         ensure that user always has email verified before he is
>>         redirected to my application as authenticated. So I may want
>>         to trigger OIDC flow with "kc_action" even before user is
>>         authenticated.
>>
>>     A few points here:
>>
>>     * AIA are there to specifically run an action, not to request
>>     some sort of condition on the user account.
>>     kc_action=verify_email would run the verify email regardless if
>>     email is verified or not.
>>     * AIA are there for an application to allow a user to initiate an
>>     action from within an external app. It's not really there for the
>>     app to request things out of bounds.
>
>     Well, that is the question? In current Account management, we show
>     the link "Link Facebook" just in case that user is not yet linked
>     with Facebook. Similarly if user is already linked, we display the
>     link "Unlink Facebook" . It seems to me that people will often do
>     those actions based on the state of the account (EG. I want to
>     display link "Verify Email" in my application, just in case that
>     user doesn't yet have verified email).
>
>
> Application has both the account REST API and the token available to 
> discover information about the user account. Through account rest it 
> would discover that Facebook is already linked or not. Hence, you do 
> actually need to be already logged-in regardless.
>
>     Maybe I am wrong and this is not so important, we may see in the
>     future...
>
>     Marek
>
>>         Will be also nice for the "Terms and Conditions" actions as
>>         the "Terms and Conditions" pages are often client specific,
>>         so our current approach with generic "Terms and Conditions"
>>         action is likely not so nice and requires that many
>>         application implements some equivalent of app-specific "Terms
>>         and Conditions" page on their side rather than rely on
>>         Keycloak. But with those "Application Initiated Actions" we
>>         can improve on here.
>>
>>     As far as I know we have never had a request for client specific
>>     terms and conditions. Not sure that is something Keycloak should
>>     ever consider, besides if we did that doesn't need kc_action, but
>>     rather just some way to configure different terms based on the
>>     client.
>>
>>         Marek
>>
>>>
>>>         On Fri, 22 Mar 2019 at 12:42, Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>
>>>
>>>             On Fri, 22 Mar 2019 at 12:07, Marek Posolda
>>>             <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>                 I am sorry to join this so late.
>>>
>>>                 My concern is, that in the design, it was mentioned
>>>                 that consent will be
>>>                 always required from the user. I understand that
>>>                 this simplifies the
>>>                 flow as it's more secure and not need to
>>>                 authenticate the client.
>>>                 However from the usability perspective, it doesn't
>>>                 look so nice to me.
>>>
>>>                 For example assume that in the application, the user
>>>                 just clicked on the
>>>                 button "Link my account with Facebook" . Then after
>>>                 login with Facebook,
>>>                 he will see another splash screen like "Application
>>>                 XY wants to link
>>>                 your account with Facebook", which he needs to
>>>                 confirm. It may be
>>>                 especially bad for usability in this case with
>>>                 linking social accounts,
>>>                 as user may see one splash screen shown by Facebook
>>>                 "Application
>>>                 keycloak wants to access your Facebook profile and
>>>                 email" and then
>>>                 immediately another splash screen shown by Keycloak
>>>                 "Application Foo
>>>                 wants to link your account with Facebook" .
>>>
>>>                 Maybe I am wrong, but my guess is, that our users
>>>                 will very quickly come
>>>                 with requirement "Can I ommit to show the splash
>>>                 screen?" . It is bit
>>>                 similar to the "Consent Required" switch, which I
>>>                 guess most people have
>>>                 OFF for their clients. So IMO I would rather count
>>>                 with this from the
>>>                 beginning and count with the fact, that we will need
>>>                 to ommit consent
>>>                 screen and hence verify client.
>>>
>>>                 With regards to this, It seems that we may need also
>>>                 to specify if
>>>                 client is:
>>>                 - Allowed to initiate action
>>>                 - Allowed to initate action with the consent required
>>>                 - Allowed to initate action with no-consent required
>>>                 Maybe the "Consent required" switch can be on
>>>                 instead on the action
>>>                 itself, but the will still need to restrict if
>>>                 client is allowed or not
>>>                 to perform the action.
>>>
>>>
>>>             I can see your point for linking to external IdP.
>>>
>>>             However, for everything else the actions are requesting
>>>             a user to enter information before something happens.
>>>             I.e. registering WebAuthn device, update password, etc..
>>>             All require the user to first fill in the form.
>>>
>>>
>>>                 With regards to the flow, I suggest that KC will
>>>                 require full
>>>                 OIDC/OAuth2 flow. In other words, when KC redirects
>>>                 back to the client,
>>>                 the client will be required to send code-to-token
>>>                 request. And the
>>>                 action (EG. Keycloak user linked with Facebook) is
>>>                 done *after* the
>>>                 whole flow (including code-to-token flow) is
>>>                 finished. That should be
>>>                 sufficient to verify the client and at the same
>>>                 time, it will allow us
>>>                 to add some more things to tokens (EG. some facebook
>>>                 details) . Downside
>>>                 is, that it will be harder to implement though as
>>>                 the SPI will likely
>>>                 need another callback after code-to-token flow to
>>>                 "finish" the action...
>>>
>>>
>>>             I don't think I understand, because if you are proposing
>>>             what I'm thinking it sounds awkward. Can you list the flow?
>>>
>>>
>>>                 Last thing, I was thinking about using "scope"
>>>                 parameter to reference
>>>                 those actions instead of have proprietary
>>>                 "kc_action" thing. The we
>>>                 don't need any extensions of OIDC. It may simplify
>>>                 things like consents
>>>                 etc. Also client will be able to have something
>>>                 similar like we have in
>>>                 "Client Scopes" tab - the list of action, which he
>>>                 is allowed to
>>>                 initiate. But I am not sure about this last point
>>>                 and maybe it's better
>>>                 to keep things separated...
>>>
>>>
>>>             I'm not convinced using scope param makes sense. It just
>>>             doesn't fit in my mental model.
>>>
>>>
>>>                 Marek
>>>
>>>
>>>
>>>
>>>                 On 21/03/2019 14:07, Pedro Igor Silva wrote:
>>>                 > Sure, I'm not against the initial design/scope.
>>>                 Just tried to make comments
>>>                 > about other aspects that, to me, are related or
>>>                 how it can be leveraged to
>>>                 > also achieve other things.
>>>                 >
>>>                 > So, what Stian plans mentioned in one of his
>>>                 replies is fine for me.
>>>                 >
>>>                 > On Thu, Mar 21, 2019 at 9:47 AM Stan Silvert
>>>                 <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>>>                 wrote:
>>>                 >
>>>                 >> Pedro,
>>>                 >>
>>>                 >> My only concern is getting this nailed down so we
>>>                 can move forward with
>>>                 >> the new account console.
>>>                 >>
>>>                 >> It sounds like Stian's proposal is simpler, but
>>>                 covers fewer use cases.
>>>                 >> Is that correct?
>>>                 >>
>>>                 >> Would it be practical to implement Stian's plan
>>>                 and then implement your
>>>                 >> proposal at a later date?
>>>                 >>
>>>                 >> On 3/21/2019 8:05 AM, Pedro Igor Silva wrote:
>>>                 >>> In addition to everything you said.
>>>                 >>>
>>>                 >>> * It is not only about making changes to
>>>                 account, but updating tokens
>>>                 >> with
>>>                 >>> information from required actions, which not
>>>                 necessarily need to be
>>>                 >>> persisted.
>>>                 >>>
>>>                 >>> * For back-end applications, we could also
>>>                 associate these required
>>>                 >> actions
>>>                 >>> with scopes. If we could have a required action
>>>                 as "Re-authenticate" or
>>>                 >>> "Provide 2nd factor", that would also help with
>>>                 step-up authentication.
>>>                 >> As
>>>                 >>> an alternative to OIDC acr related
>>>                 parameters/claims. I don't think it
>>>                 >>> makes sense to bring to the client concerns that
>>>                 are really tied to the
>>>                 >>> scopes of a resource server. As I said, clients
>>>                 should ask for scopes and
>>>                 >>> Keycloak should do whatever is necessary to
>>>                 grant these (via consent, via
>>>                 >>> additional steps/actions). Consider what you
>>>                 mentioned at the end of your
>>>                 >>> design document at "Require Re-Authentication".
>>>                 Couldn't we leverage AIA
>>>                 >>> for step-up and ask the user for a more stronger
>>>                 credential ?
>>>                 >>>
>>>                 >>> * Claims gathering flow is simple. The Keycloak
>>>                 server would return the
>>>                 >>> endpoint to where the client should redirect the
>>>                 user. After obtaining
>>>                 >>> information from the user, Keycloak would issue
>>>                 a ticket (instead of
>>>                 >> code).
>>>                 >>> The endpoint returned by Keycloak would contain
>>>                 the action associated
>>>                 >> with
>>>                 >>> a resource. The endpoint could be the same as
>>>                 what you are using for AIA.
>>>                 >>>
>>>                 >>>
>>>                 >>>
>>>                 >>>
>>>                 >>>
>>>                 >>> On Thu, Mar 21, 2019 at 4:13 AM Stian Thorgersen
>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>                 >>> wrote:
>>>                 >>>
>>>                 >>>> Pedro,
>>>                 >>>>
>>>                 >>>> I really don't understand what your points are
>>>                 and what you propose we
>>>                 >> do
>>>                 >>>> here.
>>>                 >>>>
>>>                 >>>> The use-case we're addressing is the following:
>>>                 >>>>
>>>                 >>>> As a user I would like to initiate an action
>>>                 associated with my account
>>>                 >>>> through a front-end application so that I can
>>>                 make changes to my
>>>                 >> account,
>>>                 >>>> for example to register a WebAuthn security key
>>>                 with my account.
>>>                 >>>>
>>>                 >>>> Further, we want an action to be implemented
>>>                 once and re-usable in
>>>                 >>>> login/registration flows as well as from
>>>                 applications managing user
>>>                 >>>> accounts, incuding our new account console.
>>>                 That means our new account
>>>                 >>>> console needs to be able to invoke an action in
>>>                 the login flow,
>>>                 >> otherwise
>>>                 >>>> we would have to implement actions as
>>>                 react/rest also.
>>>                 >>>>
>>>                 >>>> Now the solution I have proposed is simple. It
>>>                 allows an application to
>>>                 >>>> request an action being invoked after the user
>>>                 has authenticated. Think
>>>                 >> of
>>>                 >>>> it as a "required action" on-demand. It can be
>>>                 implemented with a few
>>>                 >> lines
>>>                 >>>> of code and easily tested. It is very easy to
>>>                 use as it just means
>>>                 >> adding
>>>                 >>>> an extra query param to the login flows, which
>>>                 makes it very easy to use
>>>                 >>>> both for confidential and non-confidential clients.
>>>                 >>>>
>>>                 >>>> It is not trying to cover claims gathering
>>>                 use-case from UMA. I see no
>>>                 >>>> connection to this and step-up authentication.
>>>                 These both already have
>>>                 >>>> clearly defined protocols. Neither can be used
>>>                 to address the above
>>>                 >>>> use-case.
>>>                 >>>>
>>>                 >>>> So please come with a concrete proposal as I
>>>                 have no clue what your
>>>                 >>>> objections are.
>>>                 >>>>
>>>                 >>>> On Wed, 20 Mar 2019 at 19:37, Pedro Igor Silva
>>>                 <psilva at redhat.com <mailto:psilva at redhat.com>>
>>>                 >> wrote:
>>>                 >>>>> On Wed, Mar 20, 2019 at 1:33 PM Stian
>>>                 Thorgersen <sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>>
>>>                 >>>>> wrote:
>>>                 >>>>>
>>>                 >>>>>> On Wed, 20 Mar 2019 at 17:19, Pedro Igor
>>>                 Silva <psilva at redhat.com <mailto:psilva at redhat.com>>
>>>                 >>>>>> wrote:
>>>                 >>>>>>
>>>                 >>>>>>> On Wed, Mar 20, 2019 at 12:28 PM Stian
>>>                 Thorgersen <
>>>                 >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>                 >>>>>>> wrote:
>>>                 >>>>>>>
>>>                 >>>>>>>> On Wed, 20 Mar 2019 at 16:02, Pedro Igor
>>>                 Silva <psilva at redhat.com <mailto:psilva at redhat.com>>
>>>                 >>>>>>>> wrote:
>>>                 >>>>>>>>
>>>                 >>>>>>>>> On Fri, Mar 8, 2019 at 4:17 AM Stian
>>>                 Thorgersen <
>>>                 >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>                 >>>>>>>>> wrote:
>>>                 >>>>>>>>>
>>>                 >>>>>>>>>> On Thu, 7 Mar 2019 at 19:09, Pedro Igor
>>>                 Silva <psilva at redhat.com <mailto:psilva at redhat.com>>
>>>                 >>>>>>>>>> wrote:
>>>                 >>>>>>>>>>
>>>                 >>>>>>>>>>> On Thu, Mar 7, 2019 at 12:33 PM Stian
>>>                 Thorgersen <
>>>                 >>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>> wrote:
>>>                 >>>>>>>>>>>
>>>                 >>>>>>>>>>>> Is it this stuff you're thinking about:
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>>>
>>>                 >>
>>>                 https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#claim-redirect
>>>                 >>>>>>>>>>>>? ?From that it does a get including the
>>>                 ticket as a query
>>>                 >> parameter.
>>>                 >>>>>>>>>>>> I don't like the idea of sending
>>>                 tickets as query params as
>>>                 >> they could be
>>>                 >>>>>>>>>>>> logged. For the application initiated
>>>                 action it would have to
>>>                 >> be an ID
>>>                 >>>>>>>>>>>> token sent as the ticket. Or as I
>>>                 mentioned before perhaps we
>>>                 >> have a way of
>>>                 >>>>>>>>>>>> creating a ticket that can only be used
>>>                 to initiate an action.
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>> Why you need to send the id token if the
>>>                 client already got an id
>>>                 >>>>>>>>>>> token and, considering browser flow,
>>>                 there is a cookie that can
>>>                 >> be used by
>>>                 >>>>>>>>>>> Keycloak to identify the client/user ?
>>>                 >>>>>>>>>>>
>>>                 >>>>>>>>>> Cookie doesn't authenticate the client,
>>>                 only the user.
>>>                 >>>>>>>>>>
>>>                 >>>>>>>>> But the identity cookie has the user
>>>                 session and from it we can
>>>                 >> check
>>>                 >>>>>>>>> whether or not the client initiating the
>>>                 action (client_id) has a
>>>                 >>>>>>>>> authenticated client session, no ?
>>>                 >>>>>>>>>
>>>                 >>>>>>>> That only proves that the client_id belongs
>>>                 to a client that has
>>>                 >>>>>>>> obtained a token. It doesn't authenticate
>>>                 the client in any way.
>>>                 >>>>>>>>
>>>                 >>>>>>>> Q- Why is authentication of the client
>>>                 required? IMO it is not
>>>                 >>>>>>>> required.
>>>                 >>>>>>>>
>>>                 >>>>>>> Sure, but the client obtained token and is
>>>                 authenticated, thus acting
>>>                 >>>>>>> on behalf of the user. If the client is
>>>                 already acting on behalf of
>>>                 >> a user,
>>>                 >>>>>>> we don't need to authenticate it.
>>>                 >>>>>>>
>>>                 >>>>>> That's not correct. All we know is that a
>>>                 client with the same
>>>                 >> client_id
>>>                 >>>>>> has obtained a token. Anyone can use the same
>>>                 client_id to initiate an
>>>                 >>>>>> action.
>>>                 >>>>>>
>>>                 >>>>>>
>>>                 >>>>>>>>>>>> Perhaps what we could do is:
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>>> 1. By default any application can
>>>                 initiate an action
>>>                 >>>>>>>>>>>> 1.1. To initiate an action there's no
>>>                 need for a ticket of any
>>>                 >>>>>>>>>>>> sort, just a regular oauth flow
>>>                 >>>>>>>>>>>> 2. Later add support if demand to limit
>>>                 what applications can
>>>                 >>>>>>>>>>>> initiate actions
>>>                 >>>>>>>>>>>> 2.1 Same as before if the action being
>>>                 initiated is open for
>>>                 >>>>>>>>>>>> everyone then no need for a ticket
>>>                 >>>>>>>>>>>> 2.2 If the action being initiated is
>>>                 only permitted by some
>>>                 >>>>>>>>>>>> applications we would need some form of
>>>                 authentication.
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>>> For 2.2 I have 3 suggestions in mind:
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>>> a. Just include id_token as a ticket
>>>                 query param like? UMA claim
>>>                 >>>>>>>>>>>> redirect does
>>>                 >>>>>>>>>>>> b. Add support to obtain an initiate
>>>                 action ticket from a
>>>                 >> endpoint
>>>                 >>>>>>>>>>>> using an id token as bearer token
>>>                 >>>>>>>>>>>> c. Add a note into client session with
>>>                 a initiate action ticket
>>>                 >>>>>>>>>>>> for clients that can initiate actions
>>>                 and map this into the id
>>>                 >> token.
>>>                 >>>>>>>>>>> Not sure ...
>>>                 >>>>>>>>>>>
>>>                 >>>>>>>>>>> If you think about it, the part
>>>                 interested in obtaining the
>>>                 >> claims
>>>                 >>>>>>>>>>> after an action is completed is not the
>>>                 client but the audience
>>>                 >> of the
>>>                 >>>>>>>>>>> token, the resource server. In this
>>>                 case, the UMA approach seems
>>>                 >> more
>>>                 >>>>>>>>>>> appropriate because the resource server
>>>                 is in control about what
>>>                 >> actions
>>>                 >>>>>>>>>>> the client should initiate in order to
>>>                 fulfill the constraints
>>>                 >> imposed by
>>>                 >>>>>>>>>>> the resource server to access its
>>>                 protected resources. Where
>>>                 >> these
>>>                 >>>>>>>>>>> constraints could be a DOB in the token
>>>                 or a higher security
>>>                 >> level.
>>>                 >>>>>>>>>>> The app initiating actions in the server
>>>                 is not the goal, but the
>>>                 >>>>>>>>>>> tool to obtain additional claims from
>>>                 the server ...
>>>                 >>>>>>>>>>>
>>>                 >>>>>>>>>>> However, for some applications acting as
>>>                 both client and resource
>>>                 >>>>>>>>>>> server (e.g.: a monolithic jee) can
>>>                 avoid all the ticket dance
>>>                 >> and just
>>>                 >>>>>>>>>>> redirect the user to the server as you
>>>                 pointed out in 1.
>>>                 >>>>>>>>>>>
>>>                 >>>>>>>>>> Perhaps there's a case for that, but that
>>>                 would be claims
>>>                 >> gathering,
>>>                 >>>>>>>>>> not application initiated actions.
>>>                 >>>>>>>>>>
>>>                 >>>>>>>>>> Application initiated actions are more a
>>>                 tool for folks to add
>>>                 >>>>>>>>>> actions for the user account into their
>>>                 own GUIs, and as such
>>>                 >> should be a
>>>                 >>>>>>>>>> simple protocol. OAuth incremental scopes
>>>                 for example doesn't
>>>                 >> have any
>>>                 >>>>>>>>>> flows between app and service, but rather
>>>                 just allows the app to
>>>                 >> get the
>>>                 >>>>>>>>>> scopes it out of bounds knows it needs
>>>                 for specific actions.
>>>                 >>>>>>>>>>
>>>                 >>>>>>>>> I think claims gathering and AIA are
>>>                 pretty much the same thing.
>>>                 >> Both
>>>                 >>>>>>>>> are querying the user for additional
>>>                 information. Despite if you
>>>                 >> are
>>>                 >>>>>>>>> initiating an action to request user's DOB
>>>                 or update a password,
>>>                 >> they are
>>>                 >>>>>>>>> steps that the user must perform in order
>>>                 to enrich its security
>>>                 >> context
>>>                 >>>>>>>>> and be able to continue using both client
>>>                 and resource server.
>>>                 >>>>>>>>>
>>>                 >>>>>>>>> The point I'm trying to make is that AIA
>>>                 can solve other problems
>>>                 >>>>>>>>> too. You would still solve the original
>>>                 problem from your design
>>>                 >> document
>>>                 >>>>>>>>> as defined in the motivation section.
>>>                 While you would also help
>>>                 >> with
>>>                 >>>>>>>>> step-up authentication and UMA claims
>>>                 gathering. Another point is
>>>                 >> related
>>>                 >>>>>>>>> to the party interested in the action. Is
>>>                 it the client or the
>>>                 >> resource
>>>                 >>>>>>>>> server (the API)?
>>>                 >>>>>>>>>
>>>                 >>>>>>>>> If the client (which honestly I don't see
>>>                 much use as most apps
>>>                 >> seem
>>>                 >>>>>>>>> to be a combination of front-end +
>>>                 back-end, where the
>>>                 >> functionality is
>>>                 >>>>>>>>> provided by the back-end and protected by
>>>                 a bearer token) then you
>>>                 >> may just
>>>                 >>>>>>>>> consider passing the "kc_action" parameter
>>>                 and have the action
>>>                 >> initiated.
>>>                 >>>>>>>>> If the resource server, you could
>>>                 associate the required actions
>>>                 >> with
>>>                 >>>>>>>>> the scopes. So when a client requests a
>>>                 specific scope, Keycloak
>>>                 >> will start
>>>                 >>>>>>>>> the action(s) and query the user for some
>>>                 information prior to
>>>                 >> issuing the
>>>                 >>>>>>>>> access token.
>>>                 >>>>>>>>>
>>>                 >>>>>>>>> Still, if the resource server, the
>>>                 resource server could respond to
>>>                 >>>>>>>>> the client (e.g: UMA flow) indicating that
>>>                 it needs more info,
>>>                 >> then the
>>>                 >>>>>>>>> client will just redirect the user to the
>>>                 location provided in the
>>>                 >> response
>>>                 >>>>>>>>> to initiate the actions.
>>>                 >>>>>>>>>
>>>                 >>>>>>>> I don't understand what your point is or
>>>                 what you are proposing
>>>                 >> here.
>>>                 >>>>>>> And I do understand your point of view. I
>>>                 just think that it can do
>>>                 >>>>>>> much more than address new account
>>>                 management console requirements.
>>>                 >>>>>>>
>>>                 >>>>>>> Based on your design document, I understand
>>>                 what you described in the
>>>                 >>>>>>> Motivation section. But again, instead of
>>>                 considering the "two
>>>                 >> things" that
>>>                 >>>>>>> originated the idea behind AIA, I think we
>>>                 can take the opportunity
>>>                 >> and do
>>>                 >>>>>>> much more. As they seem related to me.
>>>                 Especially after your DOB
>>>                 >> example.
>>>                 >>>>>> I don't see the additional use-cases you are
>>>                 mentioning as related at
>>>                 >>>>>> all.
>>>                 >>>>>>
>>>                 >>>>> How it is not related ? The audience of the
>>>                 information gathered during
>>>                 >>>>> the AIA does impact where the token with the
>>>                 information will be used.
>>>                 >> If I
>>>                 >>>>> need a DOB to access some page in my
>>>                 front-end, this is one thing. If I
>>>                 >>>>> need DOB to access some resource protected by
>>>                 a resource server it is
>>>                 >>>>> another thing. Both require tokens with
>>>                 different audiences, the former
>>>                 >>>>> will probably be an ID Token where the latter
>>>                 the access token.
>>>                 >>>>>
>>>                 >>>>> In OAuth2 the scopes represent the permissions
>>>                 to access protected
>>>                 >>>>> resources. Thus, it does make sense to have
>>>                 required actions that can
>>>                 >>>>> challenge a user when requesting scopes.
>>>                 Considering your DOB example,
>>>                 >> if
>>>                 >>>>> my client wants to access resource
>>>                 /api/age/check why you want the
>>>                 >> client
>>>                 >>>>> to request kc_action=dob if the scope "dob" is
>>>                 what he needs to access
>>>                 >> the
>>>                 >>>>> API ? Otherwise, you are making the client
>>>                 aware of things that are
>>>                 >> really
>>>                 >>>>> related to the resource server. It is OK the
>>>                 client ask for scope
>>>                 >> "age", it
>>>                 >>>>> is how OAuth2 authorization model works.
>>>                 >>>>>
>>>                 >>>>> UMA leverages OAuth2 in a way that the
>>>                 permission ticket makes the
>>>                 >> client
>>>                 >>>>> really dumb about what it needs to access
>>>                 protected resources. With
>>>                 >> UMA,
>>>                 >>>>> the client will just receive a ticket and with
>>>                 that ticket it can
>>>                 >> perform
>>>                 >>>>> the necessary actions to make a successful
>>>                 authorization request to the
>>>                 >>>>> server.
>>>                 >>>>>
>>>                 >>>>>
>>>                 >>>>>> * Step-up authentication has already clear
>>>                 parameters in OIDC/OAuth to
>>>                 >>>>>> request high level of authentication. On the
>>>                 implementation side it's
>>>                 >> about
>>>                 >>>>>> invoking additional parts of the
>>>                 authentication flow, not to initiate
>>>                 >> an
>>>                 >>>>>> required action that has nothing to do with
>>>                 the authentication flow.
>>>                 >>>>>>
>>>                 >>>>> Can we consider a required action as a prompt
>>>                 for 2nd factor, for
>>>                 >>>>> instance ?
>>>                 >>>>>
>>>                 >>>>>
>>>                 >>>>>> * Claims gathering in UMA is about asking the
>>>                 user for additional
>>>                 >>>>>> claims. AIA can be used as a poor-mans
>>>                 workaround to lack of claims
>>>                 >>>>>> gathering, but end of the day it's completely
>>>                 different. AIA will
>>>                 >> allow an
>>>                 >>>>>> app to invoke the action update_DOB, while
>>>                 claims gaterhing will
>>>                 >> allow the
>>>                 >>>>>> application to request the claim DOB.
>>>                 >>>>>>
>>>                 >>>>> Not sure, if the difference is due to updating
>>>                 a piece of info, both
>>>                 >>>>> flows request the user for the info. Is just a
>>>                 matter of updating or
>>>                 >> not
>>>                 >>>>> updating the info.
>>>                 >>>>>
>>>                 >>>>>
>>>                 >>>>>> I don't see what additional things we need to
>>>                 consider for something
>>>                 >>>>>> that is in the end very simple and can be
>>>                 implemented in a couple
>>>                 >> hours
>>>                 >>>>>> including tests if we don't try to make it
>>>                 more complicated.
>>>                 >>>>>>
>>>                 >>>>>>
>>>                 >>>>>>>>>>>> On Thu, 7 Mar 2019 at 16:19, Stian
>>>                 Thorgersen <
>>>                 >> sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>                 >>>>>>>>>>>> wrote:
>>>                 >>>>>>>>>>>>
>>>                 >>>>>>>>>>>>> On Thu, 7 Mar 2019 at 13:39, Pedro
>>>                 Igor Silva <
>>>                 >> psilva at redhat.com <mailto:psilva at redhat.com>>
>>>                 >>>>>>>>>>>>> wrote:
>>>                 >>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 3:45 PM Stian
>>>                 Thorgersen <
>>>                 >>>>>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 17:39, Pedro
>>>                 Igor Silva <
>>>                 >>>>>>>>>>>>>>> psilva at redhat.com
>>>                 <mailto:psilva at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 1:30 PM
>>>                 Stian Thorgersen <
>>>                 >>>>>>>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>> Why do you think
>>>                 authentication/authorization is required?
>>>                 >>>>>>>>>>>>>>>>> The user will be prompted before
>>>                 making an action and it's
>>>                 >> an action they
>>>                 >>>>>>>>>>>>>>>>> do against RH-SSO and not
>>>                 automatically visible/exposed to
>>>                 >> the client.
>>>                 >>>>>>>>>>>>>>>> The client is making the request
>>>                 and even though the user is
>>>                 >>>>>>>>>>>>>>>> at the Keycloak server to perform
>>>                 the action, admins may
>>>                 >> want to restrict
>>>                 >>>>>>>>>>>>>>>> which clients are allowed to
>>>                 perform such actions. That is
>>>                 >> what I mean by
>>>                 >>>>>>>>>>>>>>>> some level of authorization.
>>>                 >>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>> You could even consider not
>>>                 authenticating the client at
>>>                 >> all,
>>>                 >>>>>>>>>>>>>>>> but still allow admins to enforce
>>>                 which clients should be
>>>                 >> allowed to
>>>                 >>>>>>>>>>>>>>>> initiate actions on the server.
>>>                 >>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>> I can't see how enforcing which
>>>                 clients is allowed to
>>>                 >> initiate
>>>                 >>>>>>>>>>>>>>> actions will work without
>>>                 authenticating the client.
>>>                 >>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>> Maybe the word authenticate seems too
>>>                 much to what we are
>>>                 >>>>>>>>>>>>>> discussing. This is more a validation
>>>                 of the client making
>>>                 >> the request.
>>>                 >>>>>>>>>>>>>> Considering that, I'm saying that you
>>>                 could just rely on
>>>                 >> client_id and
>>>                 >>>>>>>>>>>>>> redirect uris (the client is already
>>>                 authenticated and if
>>>                 >> doing browser
>>>                 >>>>>>>>>>>>>> authentication the cookie is already
>>>                 present) and possibly
>>>                 >> add some level
>>>                 >>>>>>>>>>>>>> of authorization to enforce which
>>>                 clients can perform actions
>>>                 >> (instead of
>>>                 >>>>>>>>>>>>>> just relying on the authenticated
>>>                 session). Redirect uris are
>>>                 >> really
>>>                 >>>>>>>>>>>>>> important because you want to make
>>>                 sure the redirect uri is
>>>                 >> valid before
>>>                 >>>>>>>>>>>>>> redirecting the user.
>>>                 >>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>> The plan is to use the auth endpoint,
>>>                 so client_id and
>>>                 >>>>>>>>>>>>> redirect_uris are already being
>>>                 checked. It's just a standard
>>>                 >> OAuth flow.
>>>                 >>>>>>>>>>>>> IMO that's fine as long as there's no
>>>                 need to limit what
>>>                 >> clients
>>>                 >>>>>>>>>>>>> can initiate actions. If that's needed
>>>                 then we need something
>>>                 >> more
>>>                 >>>>>>>>>>>>> complicated that properly
>>>                 authenticates the client, as anyone
>>>                 >> could just
>>>                 >>>>>>>>>>>>> use the client_id and redirect_uri
>>>                 from a different
>>>                 >> application to get the
>>>                 >>>>>>>>>>>>> action initiated (although wouldn't
>>>                 then have the user
>>>                 >> redirected back to
>>>                 >>>>>>>>>>>>> the app of course).
>>>                 >>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:31, Pedro
>>>                 Igor Silva <
>>>                 >>>>>>>>>>>>>>>>> psilva at redhat.com
>>>                 <mailto:psilva at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>> One way is to follow
>>>                 authorization code constraints like
>>>                 >>>>>>>>>>>>>>>>>> checking the client_id and
>>>                 redirect_uri (assuming the
>>>                 >> user will be
>>>                 >>>>>>>>>>>>>>>>>> redirected back after the action
>>>                 completes). But still,
>>>                 >> we could also add
>>>                 >>>>>>>>>>>>>>>>>> some level authorization.
>>>                 >>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>> authorization code constraints
>>>                 doesn't work as anyone can
>>>                 >>>>>>>>>>>>>>>>> just use the client_id and
>>>                 redirect_uri from a different
>>>                 >> client.
>>>                 >>>>>>>>>>>>>>>> I may be missing the whole flow. I
>>>                 would ask then what
>>>                 >> happens
>>>                 >>>>>>>>>>>>>>>> after the user performs an action.
>>>                 Is he/her redirected
>>>                 >> back to the client
>>>                 >>>>>>>>>>>>>>>> ? If so, client_id + redirect_uri
>>>                 do work to make sure that
>>>                 >> the client is
>>>                 >>>>>>>>>>>>>>>> known and that the user will be
>>>                 redirected back to a valid
>>>                 >> URI.
>>>                 >>>>>>>>>>>>>>> It's just a standard OAuth flow, so
>>>                 app would get new tokens.
>>>                 >>>>>>>>>>>>>>> Say the user hasn't entered a DOB in
>>>                 the profile and the
>>>                 >> client wants that,
>>>                 >>>>>>>>>>>>>>> then they can request the user to
>>>                 enter a DOB, which would
>>>                 >> then result in
>>>                 >>>>>>>>>>>>>>> the DOB being available in the token.
>>>                 >>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>> This flow seems very closely related
>>>                 with the Claims Gathering
>>>                 >>>>>>>>>>>>>> Flow from UMA specs. We could
>>>                 probably review what is there
>>>                 >> and see if it
>>>                 >>>>>>>>>>>>>> can help to solve this problem of app
>>>                 initiated actions.
>>>                 >>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>> Go for it ;)
>>>                 >>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>> Only viable option I can think of
>>>                 is to add an endpoint
>>>                 >> where
>>>                 >>>>>>>>>>>>>>>>> the application can request a
>>>                 token to initate an action.
>>>                 >> So flow would be:
>>>                 >>>>>>>>>>>>>>>>> 1. App sends POST { action:
>>>                 <action-id> } with ID Token as
>>>                 >>>>>>>>>>>>>>>>> bearer token in header to a new
>>>                 endpoint. This would
>>>                 >> return a single use
>>>                 >>>>>>>>>>>>>>>>> token.
>>>                 >>>>>>>>>>>>>>>>> 2. App can now do the redirect
>>>                 protocol as before, but
>>>                 >>>>>>>>>>>>>>>>> instead of "?action=<action>" they
>>>                 would do
>>>                 >> "?action-token=<action token>"
>>>                 >>>>>>>>>>>>>>>>> In the JS adapter we can add a
>>>                 action(actionId) function
>>>                 >> that
>>>                 >>>>>>>>>>>>>>>>> would get the action token before
>>>                 redirecting the user.
>>>                 >>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>> Not sure what you mean about level
>>>                 authorization.
>>>                 >>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>> On Wed, Mar 6, 2019 at 10:25 AM
>>>                 Stian Thorgersen <
>>>                 >>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>> The issue is more around how to
>>>                 authenticate clients and
>>>                 >>>>>>>>>>>>>>>>>>> also the fact that clients
>>>                 wanting to initiate actions
>>>                 >> may be public
>>>                 >>>>>>>>>>>>>>>>>>> clients. We also don't want to
>>>                 invent a new protocol for
>>>                 >> this, but rather
>>>                 >>>>>>>>>>>>>>>>>>> just rely on the OIDC flows.
>>>                 >>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>> So with those constraints how
>>>                 would you authenticate the
>>>                 >>>>>>>>>>>>>>>>>>> client?
>>>                 >>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>> On Wed, 6 Mar 2019 at 14:23,
>>>                 Pedro Igor Silva <
>>>                 >>>>>>>>>>>>>>>>>>> psilva at redhat.com
>>>                 <mailto:psilva at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>> IMO, we should have some level
>>>                 of authorization for
>>>                 >>>>>>>>>>>>>>>>>>>> clients initiating an action.
>>>                 This could be as simple
>>>                 >> as leveraging authz
>>>                 >>>>>>>>>>>>>>>>>>>> in order to define white/black
>>>                 lists of clients.
>>>                 >> Similar to what a KC
>>>                 >>>>>>>>>>>>>>>>>>>> extension does in regards to
>>>                 authentication.
>>>                 >>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>> On Tue, Mar 5, 2019 at 3:15 PM
>>>                 Stian Thorgersen <
>>>                 >>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>> Was hoping for some more
>>>                 feedback from the list on this
>>>                 >>>>>>>>>>>>>>>>>>>>> one.
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>> Especially around not having
>>>                 any authentication of the
>>>                 >>>>>>>>>>>>>>>>>>>>> clients wanting to
>>>                 >>>>>>>>>>>>>>>>>>>>> initiate an action. I feel
>>>                 reasonable comfortable about
>>>                 >>>>>>>>>>>>>>>>>>>>> not securing it and
>>>                 >>>>>>>>>>>>>>>>>>>>> requiring actions to prompt
>>>                 the user before doing
>>>                 >>>>>>>>>>>>>>>>>>>>> anything, but welcome
>>>                 >>>>>>>>>>>>>>>>>>>>> others opinion on it.
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>> On Thu, 28 Feb 2019 at 11:07,
>>>                 Peter Skopek <
>>>                 >>>>>>>>>>>>>>>>>>>>> pskopek at redhat.com
>>>                 <mailto:pskopek at redhat.com>> wrote:
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>> Since there is no "silent"
>>>                 application initiated
>>>                 >> action
>>>                 >>>>>>>>>>>>>>>>>>>>> (always
>>>                 >>>>>>>>>>>>>>>>>>>>>> prompts user) possible and
>>>                 actions are predefined at
>>>                 >>>>>>>>>>>>>>>>>>>>> keycloak I see no
>>>                 >>>>>>>>>>>>>>>>>>>>>> need for the
>>>                 client/application restriction mechanism.
>>>                 >>>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2019 at 4:23
>>>                 PM Stian Thorgersen <
>>>                 >>>>>>>>>>>>>>>>>>>>> sthorger at redhat.com
>>>                 <mailto:sthorger at redhat.com>>
>>>                 >>>>>>>>>>>>>>>>>>>>>> wrote:
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Keycloak currently has
>>>                 required actions that are used
>>>                 >>>>>>>>>>>>>>>>>>>>> to prompt the user
>>>                 >>>>>>>>>>>>>>>>>>>>>> to
>>>                 >>>>>>>>>>>>>>>>>>>>>>> perform an action associated
>>>                 with their account after
>>>                 >>>>>>>>>>>>>>>>>>>>> authenticating, but
>>>                 >>>>>>>>>>>>>>>>>>>>>>> prior to being redirected to
>>>                 the application.
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Examples include: configure
>>>                 OTP, update profile,
>>>                 >>>>>>>>>>>>>>>>>>>>> validate email, etc.
>>>                 >>>>>>>>>>>>>>>>>>>>>>> One issue here is these
>>>                 actions have to be manually
>>>                 >>>>>>>>>>>>>>>>>>>>> registered with the
>>>                 >>>>>>>>>>>>>>>>>>>>>>> users account, but can not
>>>                 be initiated by
>>>                 >>>>>>>>>>>>>>>>>>>>> applications themselves. As an
>>>                 >>>>>>>>>>>>>>>>>>>>>>> example it may not be
>>>                 required by all users to verify
>>>                 >>>>>>>>>>>>>>>>>>>>> their email, but
>>>                 >>>>>>>>>>>>>>>>>>>>>> only
>>>                 >>>>>>>>>>>>>>>>>>>>>>> when they use specific
>>>                 applications.
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Keycloak also needs to
>>>                 initiate actions from the
>>>                 >>>>>>>>>>>>>>>>>>>>> account management
>>>                 >>>>>>>>>>>>>>>>>>>>>>> console. Examples: updating
>>>                 email address should
>>>                 >>>>>>>>>>>>>>>>>>>>> require verifying the
>>>                 >>>>>>>>>>>>>>>>>>>>>>> email, configuring OTP, etc.
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>>> With that in mind we are
>>>                 proposing to introduce
>>>                 >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Actions. An Application
>>>                 Initiated Action behind the
>>>                 >>>>>>>>>>>>>>>>>>>>> scenes is just a
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Required Action, but it is
>>>                 initiated by an
>>>                 >>>>>>>>>>>>>>>>>>>>> application and depending on
>>>                 >>>>>>>>>>>>>>>>>>>>>> the
>>>                 >>>>>>>>>>>>>>>>>>>>>>> action may be optional for
>>>                 the user to complete
>>>                 >>>>>>>>>>>>>>>>>>>>> (where the user can
>>>                 >>>>>>>>>>>>>>>>>>>>>> select
>>>                 >>>>>>>>>>>>>>>>>>>>>>> cancel which would return
>>>                 the user back to the
>>>                 >>>>>>>>>>>>>>>>>>>>> application).
>>>                 >>>>>>>>>>>>>>>>>>>>>>> No Application Initiated
>>>                 Actions should perform any
>>>                 >>>>>>>>>>>>>>>>>>>>> updates to the users
>>>                 >>>>>>>>>>>>>>>>>>>>>>> account without prompting
>>>                 the user first. For example
>>>                 >>>>>>>>>>>>>>>>>>>>> an application
>>>                 >>>>>>>>>>>>>>>>>>>>>>> initiated action that is
>>>                 used to link an existing
>>>                 >>>>>>>>>>>>>>>>>>>>> account to a social
>>>                 >>>>>>>>>>>>>>>>>>>>>>> provider should ask the user
>>>                 first if they want to
>>>                 >>>>>>>>>>>>>>>>>>>>> link to the provider.
>>>                 >>>>>>>>>>>>>>>>>>>>>>> To make it easy for
>>>                 applications to integrate these I
>>>                 >>>>>>>>>>>>>>>>>>>>> would like to
>>>                 >>>>>>>>>>>>>>>>>>>>>>> leverage the standard OAuth
>>>                 flows that applications
>>>                 >>>>>>>>>>>>>>>>>>>>> use to authenticate
>>>                 >>>>>>>>>>>>>>>>>>>>>>> users. So to initiate
>>>                 verify-email action the
>>>                 >>>>>>>>>>>>>>>>>>>>> application would redirect
>>>                 >>>>>>>>>>>>>>>>>>>>>> to
>>>                 >>>>>>>>>>>>>>>>>>>>>>> the authentication endpoint
>>>                 and add kc_action=<action
>>>                 >>>>>>>>>>>>>>>>>>>>> alias> query
>>>                 >>>>>>>>>>>>>>>>>>>>>>> parameter.
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 >>>>>>>>>>>>>>>>>>>>>>> One open question I have
>>>                 right now is. Assuming all
>>>                 >>>>>>>>>>>>>>>>>>>>> Application Initiated
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Actions always prompt the
>>>                 user first do we need to
>>>                 >>>>>>>>>>>>>>>>>>>>> add some mechanism in
>>>                 >>>>>>>>>>>>>>>>>>>>>>> place to restrict what
>>>                 clients/applications are
>>>                 >>>>>>>>>>>>>>>>>>>>> permitted to initiate an
>>>                 >>>>>>>>>>>>>>>>>>>>>>> action? Requiring that would
>>>                 make it harder to use
>>>                 >>>>>>>>>>>>>>>>>>>>> for applications.
>>>                 >>>>>>>>>>>>>>>>>>>>>>> One thing I would also like
>>>                 to add is the ability for
>>>                 >>>>>>>>>>>>>>>>>>>>> an Application
>>>                 >>>>>>>>>>>>>>>>>>>>>>> Initiated Action to require
>>>                 the user to
>>>                 >>>>>>>>>>>>>>>>>>>>> re-authenticate prior to
>>>                 >>>>>>>>>>>>>>>>>>>>>> performing
>>>                 >>>>>>>>>>>>>>>>>>>>>>> the action. For example
>>>                 update password should
>>>                 >>>>>>>>>>>>>>>>>>>>> require the user to enter
>>>                 >>>>>>>>>>>>>>>>>>>>>>> the current password, while
>>>                 verify email should not
>>>                 >>>>>>>>>>>>>>>>>>>>> (as it simply sends
>>>                 >>>>>>>>>>>>>>>>>>>>>> an
>>>                 >>>>>>>>>>>>>>>>>>>>>>> email with a link to continue).
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 _______________________________________________
>>>                 >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>                 >>>>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 >>>>>>>>>>>>>>>>>>>>>>>
>>>                 >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 _______________________________________________
>>>                 >>>>>>>>>>>>>>>>>>>>> keycloak-dev mailing list
>>>                 >>>>>>>>>>>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>                 >>>>>>>>>>>>>>>>>>>>>
>>>                 >>> _______________________________________________
>>>                 >>> keycloak-dev mailing list
>>>                 >>> keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 >>>
>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>                 >>
>>>                 >> _______________________________________________
>>>                 >> keycloak-dev mailing list
>>>                 >> keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>                 > _______________________________________________
>>>                 > keycloak-dev mailing list
>>>                 > keycloak-dev at lists.jboss.org
>>>                 <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
>>>
>>
>


From bruno at abstractj.org  Wed Mar 27 08:26:08 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 27 Mar 2019 09:26:08 -0300
Subject: [keycloak-dev] Migrate from dep to Go 1.11 modules
Message-ID: <20190327122608.GA11383@abstractj.org>

Good morning, 

For a long time, dependency management has been the subject of several
threads in the Golang community. Too many tools, which one is the best
and things like this.

Since Go 1.11.x, it was finally introduced some sorta of official
solution for Go development, named Go modules. And after Go 1.13
release, this is going to become the standard way of handling
dependencies[1].

That being said, I'd like to remove Dep, from Gatekeeper and move to Go
modules. The efford required to this was like 15 min of my time and I
already did it here: https://github.com/keycloak/keycloak-gatekeeper/pull/472

Please, let me know if there are any concerns around this.

[1] - https://blog.golang.org/using-go-modules

-- 

abstractj

From ieugen at netdava.com  Wed Mar 27 10:28:12 2019
From: ieugen at netdava.com (Eugen Stan)
Date: Wed, 27 Mar 2019 16:28:12 +0200
Subject: [keycloak-dev] translate keycloak
In-Reply-To: <CAJgngAfAOMnq03_gBvy_gtXhxa9wMaNY9P=f8ny7ZprV3s_doQ@mail.gmail.com>
References: <81d32d1e-1fbd-8068-1c56-b04fbe5d8652@netdava.com>
	<9e245cd6-6865-c3dd-80f3-56fa0a226c4f@netdava.com>
	<CAJgngAc3GeJrRBQqAORCOPob=OUHGSH4dxu3EgpHa+9QsbrXUg@mail.gmail.com>
	<c5da360b-ebd0-3c40-47a8-808ec5b27e7d@netdava.com>
	<CAJgngAdMjfhOS3qBf=pKocpAPBxPZ0L_q+Uvw=w-WMxT0N4TfQ@mail.gmail.com>
	<0e632a6e-3c74-0392-75df-055bb7c8e54f@netdava.com>
	<CAJgngAfAOMnq03_gBvy_gtXhxa9wMaNY9P=f8ny7ZprV3s_doQ@mail.gmail.com>
Message-ID: <a35e46cf-d7e5-7ac4-87e2-314add1492c3@netdava.com>

Hello Stian,

I've added Michal in CC. @Michal: this discussion is for using Weblate
to translate Keycloak .

I did a bit of research and Weblate does support PR's .

https://docs.weblate.org/en/latest/admin/continuous.html?highlight=continuous#pushing-changes-from-hosted-weblate


We are also slowly migrating to use "git subtree"? to manage translation
updates instead of the git submodule.
https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree

We "git subtree add --prefix translations https://path-to-git-repo.git
master --squash" and we get a single commit . I imagine that working
with PR's will probably eliminate the need for a separate git sub-project.


With these updates in mind, do you think keycloak can be migrated to use
(a self hosted or the weblate.org hosted ) Weblate instance ?

I would like to help out with this process and get involved with
Keycloak devel this way.

I think the first thing to do is establish some requirements - some of
them have been allready set in this thread.


Regards,

Eugen


La 06.02.2019 16:38, Stian Thorgersen a scris:
> I think you forgot to add Michal in CC (or perhaps you did BCC?)
>
> Due to the way to review and merge changes to Keycloak we can not
> accept direct commits to the repository. All changes have to be made
> through PRs.
>
> What would be very cool is if Weblate would support GitHub flow that
> enabled it to send PRs including comments and links to view the
> reviews of the translations easily.
>
> I don't think we can expect all contributions to come through Weblate
> and will still need to be able to accept translations coming directly
> as a PR.
>
> With that in mind and also just the fact that it would be rather
> awkward I don't like the idea of syncing the changes.
>
> The short term solution would be to setup Weblate with webhooks so it
> receives automatic updates, but still require changes to be done by
> sending a PR. Not sure if Weblate would support committing to a users
> fork rather than to the upstream repo.
>
> A longer term solution may be to consider extracting the translations
> completely into a separate repository and have separate releases for
> translations that are installed into Keycloak rather than bundled with
> Keycloak itself. One issue here though is that the English main
> translation would have to remain in the Keycloak repository. Not
> really sure about this approach either.
>
> On Tue, 5 Feb 2019 at 11:13, Eugen Stan <ieugen at netdava.com
> <mailto:ieugen at netdava.com>> wrote:
>
>     Hi Stian,
>
>
>     I've added Michal to CC (creator of Weblate) and I hope he can
>     pitch in.
>
>     I think the best thing is to go through the very good documentation on
>     continuous translation and translation workflows :
>     https://docs.weblate.org/en/latest/admin/continuous.html and
>     https://docs.weblate.org/en/latest/workflows.html
>
>     Weblate has some features that can help with batching: lazy commits
>     (commit once a day) and has some customization options on how to
>     interact with the repository.
>
>     I believe with the Review workflow, Weblate does not commit to git
>     until
>     the translation has been approved so this might work well. However it
>     will require a translator and a reviewer.
>
>     From our experience working with translators on apps - they need
>     context
>     and they need to see the translations in the app for them to
>     figure out
>     the best translation.
>
>     So most of the time we ended up doing the translation - best effort +
>     deploy + review in the app and update the texts.
>
>     It also helps to have a single or just a few translators or a glossary
>     to keep the translation consistent. Like in code, there are multiple
>     ways of translating a string and like developers, translators or end
>     users don't always agree on the result.
>
>     To have an idea on how the translation commits look, please see here
>     https://github.com/GreatPeopleInside/keycloak/commits/master .
>
>     You will see why we want to choose another git repo for this -
>     which is
>     still my recommendation - it works very well, and it is simple. We had
>     commits every 24h.
>
>     Another option is to keep the translations in another git repo
>     (working
>     repo) and manually merge them in keycloak (source) - there you control
>     the frequency and you can merge just one language. This requires a bit
>     of manual work but if it is done once a month it is ok I guess.
>
>
>     Regards,
>
>     La 05.02.2019 11:47, Stian Thorgersen a scris:
>     > Can you briefly describe how it works?
>     >
>     > With regards to repository and commits we can't use anything that
>     > commits directly to the repository. We need something where
>     updates to
>     > a single language can be batched and sent as a PR with a single
>     commit.
>     >
>     > On Tue, 5 Feb 2019 at 09:46, Eugen Stan <ieugen at netdava.com
>     <mailto:ieugen at netdava.com>
>     > <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>> wrote:
>     >
>     >? ? ?Hello Stian,
>     >
>     >
>     >? ? ?Weblate can wrok with the respository as is but it can
>     introduce a lot
>     >? ? ?of noise for the commits related to translation. That is why we
>     >? ? ?chose to
>     >? ? ?split the translations into another module.
>     >
>     >? ? ?In our case we have quite a few languages and a lot of text
>     to be
>     >? ? ?translated so there is a lot of noise commming as git
>     commits from
>     >? ? ?translators.
>     >
>     >? ? ?In keycloak I believe this will not matter that much since
>     it has less
>     >? ? ?text to be translated.
>     >
>     >? ? ?Weblate has the feature to implement translators + reviewers
>     >? ? ?processes.
>     >? ? ?It can also work with offline translation.
>     >
>     >? ? ?We had a very good experience with it so far. Michal (the
>     creator of
>     >? ? ?weblate) has proven very responsive and helpful even when we did
>     >? ? ?not pay
>     >? ? ?for maintenance. In our case we ended up paying for maintenance
>     >? ? ?because
>     >? ? ?it is worth it.
>     >
>     >? ? ?For keycloak we have the following languages translated for all
>     >? ? ?components (except Admin) with professional translators or local
>     >? ? ?people:
>     >? ? ?Arabic, Dutch, English Australia, English UK, Latvian,
>     Lithuanian,
>     >? ? ?Norwegian, Romanian, Russian, Spanish, Swedish, Vietnamese and
>     >? ? ?more are
>     >? ? ?comming.
>     >
>     >? ? ?I think the setup can be done in a day or so.
>     >
>     >? ? ?Regards,
>     >
>     >? ? ?La 05.02.2019 08:16, Stian Thorgersen a scris:
>     >? ? ?> I'm afraid using sub modules is not an option for us.
>     >? ? ?>
>     >? ? ?> I'm open to a tool to aid with translation, but we would
>     need to
>     >? ? ?> review what tools are available before selecting one. The
>     tool would
>     >? ? ?> have to be free for Open Source projects and self-hosting
>     is not an
>     >? ? ?> option. It would also have to work with the repository as
>     is and not
>     >? ? ?> require changes to where and how the translations are
>     maintained.
>     >? ? ?>
>     >? ? ?> On Mon, 4 Feb 2019 at 14:41, Eugen Stan
>     <ieugen at netdava.com <mailto:ieugen at netdava.com>
>     >? ? ?<mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>
>     >? ? ?> <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>
>     <mailto:ieugen at netdava.com <mailto:ieugen at netdava.com>>>> wrote:
>     >? ? ?>
>     >? ? ?>? ? ?Bump.
>     >? ? ?>
>     >? ? ?>? ? ?Hello again. We managed to translate some languages
>     already
>     >? ? ?and we
>     >? ? ?>? ? ?would
>     >? ? ?>? ? ?like to contribute the translations upstream and hopefully
>     >? ? ?improve the
>     >? ? ?>? ? ?translation process.
>     >? ? ?>
>     >? ? ?>? ? ?We have some feedback from our process. We use this
>     process
>     >? ? ?internally
>     >? ? ?>? ? ?and the idea is to have it working for keycloak open
>     source
>     >? ? ?>
>     >? ? ?>? ? ?Proposal for Keycloak
>     >? ? ?>
>     >? ? ?>? ? ?- We propose to move the community translations in a
>     >? ? ?separate git
>     >? ? ?>? ? ?project - just with the translations
>     >? ? ?>
>     >? ? ?>? ? ?- That repository is going to be used by Weblate as a
>     source of
>     >? ? ?>? ? ?translations ( use Free Hosted Weblate -
>     >? ? ?>? ? ?https://hosted.weblate.org/? )
>     >? ? ?>
>     >? ? ?>? ? ?- The translations project can be added as a git sub
>     module
>     >? ? ?to the
>     >? ? ?>? ? ?keycloak project
>     >? ? ?>
>     >? ? ?>? ? ?- during build the translations can be copied to the final
>     >? ? ?artifact
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?We do this allready and we can help with the code
>     >? ? ?migrations. Having
>     >? ? ?>? ? ?this setup will improve the contributions to translations
>     >? ? ?and also the
>     >? ? ?>? ? ?ability to change the translations easily.
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?WDYT?
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?Regards,
>     >? ? ?>
>     >? ? ?>? ? ?Eugen
>     >? ? ?>
>     >? ? ?>? ? ?La 01.12.2018 19:22, Eugen Stan a scris:
>     >? ? ?>? ? ?> Hello,
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> Where can we find the translation files for Keycloak and
>     >? ? ?what is the
>     >? ? ?>? ? ?> process for upstreaming them?
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> We are planning to deploy Keycloak for
>     authentication for our
>     >? ? ?>? ? ?services.
>     >? ? ?>? ? ?> We have users all accross the globe and we have
>     >? ? ?translators that
>     >? ? ?>? ? ?we can
>     >? ? ?>? ? ?> ask to translate.
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> I'm planning to push the translations upstream once
>     they are
>     >? ? ?>? ? ?done (need
>     >? ? ?>? ? ?> to get approbal on this).
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> Regards,
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?> Eugen
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?_______________________________________________
>     >? ? ?>? ? ?keycloak-dev mailing list
>     >? ? ?>? ? ?keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >? ? ?<mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >? ? ?<mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >? ? ?<mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>>
>     >? ? ?>? ? ?https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >? ? ?>
>     >
>


From jerry.saravia at virginpulse.com  Wed Mar 27 17:27:27 2019
From: jerry.saravia at virginpulse.com (Jerry Saravia)
Date: Wed, 27 Mar 2019 21:27:27 +0000
Subject: [keycloak-dev] Override "native" Keycloak providers
Message-ID: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>

Hello,



We?ve been using version 3.4.3 for a while now and are attempting to upgrade to 4.8 and we?ve run into some issues.



Summary: We have created our own providers with the same PROVIDER_ID as some of the built in providers. For example, PasswordCredentialProvider has a provider id of ?keycloak-password? and we created our own with the same id that gets loaded after the native one. This worked because in 3.4.3 providers that were using the same id would still have their factories added to the factory map.



See this link here for 3.4.3 changes:

https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100



These are the 4.8 changes

https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99



In 4.8, the fully qualified class name (FQCN) is not longer used. Instead it uses the provider id and the spi name. I can no longer use the same PROVIDER_ID as the native providers to ?override? them, but sometimes there is code that gets the provider specifically by id. For example, in the UpdatePassword required action we have this:



PasswordCredentialProvider passwordProvider = (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, PasswordCredentialProviderFactory.PROVIDER_ID);



In 3.4.3 because our provider was loaded we were able to inject into code that normally isn?t overridable. We did the same for the OIDCLoginProtocolFactory to alter some token endpoint behavior even the UpdatePassword required action itself rather than making a brand new required action that is a ?second rate? because it isn?t native to Keycloak.



Is there a solution for this in 4.8.3? I see this change was made in 4.0.0.Beta1 according to some of the history.



J


Jerry Saravia
Software Engineer
T(516) 603-6914
M516-603-6914
virginpulse.com
|virginpulse.com/global-challenge
492 Old Connecticut Path, Framingham, MA 01701, USA
Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA
Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
v2.48
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image552193.png
Type: image/png
Size: 681 bytes
Desc: image552193.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190327/a52100ee/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image065199.png
Type: image/png
Size: 687 bytes
Desc: image065199.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190327/a52100ee/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image383852.png
Type: image/png
Size: 757 bytes
Desc: image383852.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190327/a52100ee/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image365247.png
Type: image/png
Size: 30124 bytes
Desc: image365247.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190327/a52100ee/attachment-0007.png 

From thomas.darimont at googlemail.com  Wed Mar 27 18:23:04 2019
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 27 Mar 2019 23:23:04 +0100
Subject: [keycloak-dev] Override "native" Keycloak providers
In-Reply-To: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>
References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>
Message-ID: <CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>

Hello Jerry,

I encountered a similar problem with Keycloak 4.x when I needed to
implement my own SamlProtocolFactory to customize the SAML Message handling.
See: http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html
The only way I could get this to work was to add my custom extension jar to
the module.xml of the keycloak-services module,
see the link for details.

It's by far not the best solution, but at least it works.

Cheers,
Thomas

On Wed, 27 Mar 2019 at 22:28, Jerry Saravia <jerry.saravia at virginpulse.com>
wrote:

> Hello,
>
>
>
> We?ve been using version 3.4.3 for a while now and are attempting to
> upgrade to 4.8 and we?ve run into some issues.
>
>
>
> Summary: We have created our own providers with the same PROVIDER_ID as
> some of the built in providers. For example, PasswordCredentialProvider has
> a provider id of ?keycloak-password? and we created our own with the same
> id that gets loaded after the native one. This worked because in 3.4.3
> providers that were using the same id would still have their factories
> added to the factory map.
>
>
>
> See this link here for 3.4.3 changes:
>
>
> https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100
>
>
>
> These are the 4.8 changes
>
>
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99
>
>
>
> In 4.8, the fully qualified class name (FQCN) is not longer used. Instead
> it uses the provider id and the spi name. I can no longer use the same
> PROVIDER_ID as the native providers to ?override? them, but sometimes there
> is code that gets the provider specifically by id. For example, in the
> UpdatePassword required action we have this:
>
>
>
> PasswordCredentialProvider passwordProvider =
> (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class,
> PasswordCredentialProviderFactory.PROVIDER_ID);
>
>
>
> In 3.4.3 because our provider was loaded we were able to inject into code
> that normally isn?t overridable. We did the same for the
> OIDCLoginProtocolFactory to alter some token endpoint behavior even the
> UpdatePassword required action itself rather than making a brand new
> required action that is a ?second rate? because it isn?t native to Keycloak.
>
>
>
> Is there a solution for this in 4.8.3? I see this change was made in
> 4.0.0.Beta1 according to some of the history.
>
>
>
> J
>
>
> Jerry Saravia
> Software Engineer
> T(516) 603-6914
> M516-603-6914
> virginpulse.com
> |virginpulse.com/global-challenge
> 492 Old Connecticut Path, Framingham, MA 01701, USA
> Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore |
> Switzerland | United Kingdom | USA
> Confidentiality Notice: The information contained in this e-mail,
> including any attachment(s), is intended solely for use by the designated
> recipient(s). Unauthorized use, dissemination, distribution, or
> reproduction of this message by anyone other than the intended
> recipient(s), or a person designated as responsible for delivering such
> messages to the intended recipient, is strictly prohibited and may be
> unlawful. This e-mail may contain proprietary, confidential or privileged
> information. Any views or opinions expressed are solely those of the author
> and do not necessarily represent those of Virgin Pulse, Inc. If you have
> received this message in error, or are not the named recipient(s), please
> immediately notify the sender and delete this e-mail message.
> v2.48
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Mar 27 20:35:22 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Mar 2019 01:35:22 +0100
Subject: [keycloak-dev] Override "native" Keycloak providers
In-Reply-To: <CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>
References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com>
	<CAK-7U1hsOGjcZnv1BAf0GV1esEQ_Nyg3qdizoo9XT2kZTzX00A@mail.gmail.com>
Message-ID: <CAJgngAfm8ogwes79dPWwFL7WA2NBmiZg=_ZMA2fCz5wDfxwxgA@mail.gmail.com>

Instead of trying to deploy a custom provider with the same id as the
default provider you can change the default provider for an SPI. In
standalone.xml just set the default-provider for the SPI to your own. This
will work when Keycloak doesn't specify directly what provider to get.

It was never supported to load a custom provider with same ID as the
built-in providers. I believe that was a side-effect made possible when we
introduced the ability to hot deploy providers.

On Wed, 27 Mar 2019 at 23:27, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Jerry,
>
> I encountered a similar problem with Keycloak 4.x when I needed to
> implement my own SamlProtocolFactory to customize the SAML Message
> handling.
> See:
> http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html
> The only way I could get this to work was to add my custom extension jar to
> the module.xml of the keycloak-services module,
> see the link for details.
>
> It's by far not the best solution, but at least it works.
>
> Cheers,
> Thomas
>
> On Wed, 27 Mar 2019 at 22:28, Jerry Saravia <jerry.saravia at virginpulse.com
> >
> wrote:
>
> > Hello,
> >
> >
> >
> > We?ve been using version 3.4.3 for a while now and are attempting to
> > upgrade to 4.8 and we?ve run into some issues.
> >
> >
> >
> > Summary: We have created our own providers with the same PROVIDER_ID as
> > some of the built in providers. For example, PasswordCredentialProvider
> has
> > a provider id of ?keycloak-password? and we created our own with the same
> > id that gets loaded after the native one. This worked because in 3.4.3
> > providers that were using the same id would still have their factories
> > added to the factory map.
> >
> >
> >
> > See this link here for 3.4.3 changes:
> >
> >
> >
> https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100
> >
> >
> >
> > These are the 4.8 changes
> >
> >
> >
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99
> >
> >
> >
> > In 4.8, the fully qualified class name (FQCN) is not longer used. Instead
> > it uses the provider id and the spi name. I can no longer use the same
> > PROVIDER_ID as the native providers to ?override? them, but sometimes
> there
> > is code that gets the provider specifically by id. For example, in the
> > UpdatePassword required action we have this:
> >
> >
> >
> > PasswordCredentialProvider passwordProvider =
> >
> (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class,
> > PasswordCredentialProviderFactory.PROVIDER_ID);
> >
> >
> >
> > In 3.4.3 because our provider was loaded we were able to inject into code
> > that normally isn?t overridable. We did the same for the
> > OIDCLoginProtocolFactory to alter some token endpoint behavior even the
> > UpdatePassword required action itself rather than making a brand new
> > required action that is a ?second rate? because it isn?t native to
> Keycloak.
> >
> >
> >
> > Is there a solution for this in 4.8.3? I see this change was made in
> > 4.0.0.Beta1 according to some of the history.
> >
> >
> >
> > J
> >
> >
> > Jerry Saravia
> > Software Engineer
> > T(516) 603-6914
> > M516-603-6914
> > virginpulse.com
> > |virginpulse.com/global-challenge
> > 492 Old Connecticut Path, Framingham, MA 01701, USA
> > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore |
> > Switzerland | United Kingdom | USA
> > Confidentiality Notice: The information contained in this e-mail,
> > including any attachment(s), is intended solely for use by the designated
> > recipient(s). Unauthorized use, dissemination, distribution, or
> > reproduction of this message by anyone other than the intended
> > recipient(s), or a person designated as responsible for delivering such
> > messages to the intended recipient, is strictly prohibited and may be
> > unlawful. This e-mail may contain proprietary, confidential or privileged
> > information. Any views or opinions expressed are solely those of the
> author
> > and do not necessarily represent those of Virgin Pulse, Inc. If you have
> > received this message in error, or are not the named recipient(s), please
> > immediately notify the sender and delete this e-mail message.
> > v2.48
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Mar 27 20:36:27 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Mar 2019 01:36:27 +0100
Subject: [keycloak-dev] Application Initiated Actions Draft #2
Message-ID: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>

Based on feedback and also thinking about this a bit more I've now updated
the proposal for Application Initiated Actions.

Please read and comment on the update draft if you're interested.

https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md

From sguilhen at redhat.com  Wed Mar 27 22:25:04 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Wed, 27 Mar 2019 23:25:04 -0300
Subject: [keycloak-dev] Migrate from dep to Go 1.11 modules
In-Reply-To: <20190327122608.GA11383@abstractj.org>
References: <20190327122608.GA11383@abstractj.org>
Message-ID: <CA+7ohfkXayAxULhNJ5PpOx3E=NJDToSen3ZoJy_4FeA4Bz2Mtw@mail.gmail.com>

Curiously I was reading a couple of articles about this move to Go Modules
this past weekend. It seems natural to me that we move from Dep to Go
Modules in Gatekeeper.

On Wed, Mar 27, 2019 at 9:33 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> For a long time, dependency management has been the subject of several
> threads in the Golang community. Too many tools, which one is the best
> and things like this.
>
> Since Go 1.11.x, it was finally introduced some sorta of official
> solution for Go development, named Go modules. And after Go 1.13
> release, this is going to become the standard way of handling
> dependencies[1].
>
> That being said, I'd like to remove Dep, from Gatekeeper and move to Go
> modules. The efford required to this was like 15 min of my time and I
> already did it here:
> https://github.com/keycloak/keycloak-gatekeeper/pull/472
>
> Please, let me know if there are any concerns around this.
>
> [1] - https://blog.golang.org/using-go-modules
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 

STEFAN GUILHEN

PRINCIPAL SOFTWARE ENGINEER

Red Hat <https://www.redhat.com/>

sguilhen at redhat.com    M: +55-11-98117-7332
<https://red.ht/sig>
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>   Red Hat
<https://www.facebook.com/RedHatInc>

From mposolda at redhat.com  Thu Mar 28 03:59:52 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 28 Mar 2019 08:59:52 +0100
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
Message-ID: <b5c2c6fe-dbc2-9939-d157-9c22a2f33b31@redhat.com>

+1 for the proposal.

Thanks,
Marek

On 28/03/2019 01:36, Stian Thorgersen wrote:
> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
>
> Please read and comment on the update draft if you're interested.
>
> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From vramik at redhat.com  Thu Mar 28 05:26:50 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Thu, 28 Mar 2019 10:26:50 +0100
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <b5c2c6fe-dbc2-9939-d157-9c22a2f33b31@redhat.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
	<b5c2c6fe-dbc2-9939-d157-9c22a2f33b31@redhat.com>
Message-ID: <bf9dc067-75c4-d3e2-969f-9b0942760ca1@redhat.com>

I like the proposal,

Thanks,

V.

On 3/28/19 8:59 AM, Marek Posolda wrote:
> +1 for the proposal.
>
> Thanks,
> Marek
>
> On 28/03/2019 01:36, Stian Thorgersen wrote:
>> Based on feedback and also thinking about this a bit more I've now updated
>> the proposal for Application Initiated Actions.
>>
>> Please read and comment on the update draft if you're interested.
>>
>> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.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 fredbi at yahoo.com  Thu Mar 28 06:52:49 2019
From: fredbi at yahoo.com (BIDON Frederic)
Date: Thu, 28 Mar 2019 10:52:49 +0000 (UTC)
Subject: [keycloak-dev] Migrate from dep to Go 1.11 modules
In-Reply-To: <CA+7ohfkXayAxULhNJ5PpOx3E=NJDToSen3ZoJy_4FeA4Bz2Mtw@mail.gmail.com>
References: <20190327122608.GA11383@abstractj.org>
	<CA+7ohfkXayAxULhNJ5PpOx3E=NJDToSen3ZoJy_4FeA4Bz2Mtw@mail.gmail.com>
Message-ID: <633514821.12463129.1553770369694@mail.yahoo.com>

[keycloak-gatekeeper]
We have migrated to modules with our fork and it is working fine.
There are still a couple obsolete dependencies issues that do not resolve well with modules.Hope I'll find some time soon to push the adequate PRs to master.

Fr?d?ri 
?frederic.bidon at yahoo.com? 

    On Thursday, March 28, 2019, 3:29:50 AM GMT+1, Stefan Guilhen <sguilhen at redhat.com> wrote:  
 
 Curiously I was reading a couple of articles about this move to Go Modules
this past weekend. It seems natural to me that we move from Dep to Go
Modules in Gatekeeper.

On Wed, Mar 27, 2019 at 9:33 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> For a long time, dependency management has been the subject of several
> threads in the Golang community. Too many tools, which one is the best
> and things like this.
>
> Since Go 1.11.x, it was finally introduced some sorta of official
> solution for Go development, named Go modules. And after Go 1.13
> release, this is going to become the standard way of handling
> dependencies[1].
>
> That being said, I'd like to remove Dep, from Gatekeeper and move to Go
> modules. The efford required to this was like 15 min of my time and I
> already did it here:
> https://github.com/keycloak/keycloak-gatekeeper/pull/472
>
> Please, let me know if there are any concerns around this.
>
> [1] - https://blog.golang.org/using-go-modules
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 

STEFAN GUILHEN

PRINCIPAL SOFTWARE ENGINEER

Red Hat <https://www.redhat.com/>

sguilhen at redhat.com? ? M: +55-11-98117-7332
<https://red.ht/sig>
@RedHat <https://twitter.com/redhat>? Red Hat
<https://www.linkedin.com/company/red-hat>? Red Hat
<https://www.facebook.com/RedHatInc>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
  

From ssilvert at redhat.com  Thu Mar 28 08:43:48 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 28 Mar 2019 08:43:48 -0400
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
Message-ID: <6d4a4d1e-4e10-774e-66e9-9f3656d16d55@redhat.com>

+1 from me as well.

Thinking in terms of Account Console, I'm starting to wonder if AIA's 
mean we need to take a fresh look from a UXD perspective. Almost half of 
the functionality will be taken over by AIA.? So that means a lot of 
what is currently in the navigation menu results in a new screen that 
replaces the console.? It's no longer "click a link and get something 
new in the content area".

If everything was implemented as AIA then the Account Console would 
become more of an application launcher.? But sounds like we will end up 
with a hybrid or some sort.

Stan

On 3/27/2019 8:36 PM, Stian Thorgersen wrote:
> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
>
> Please read and comment on the update draft if you're interested.
>
> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From demetrio at carretti.pro  Thu Mar 28 12:06:44 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Thu, 28 Mar 2019 19:06:44 +0300
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
Message-ID: <1553789204.3600.7.camel@carretti.pro>

Hi,

I'm currently working to implement the following requirements:
- users are managed externally via LDAP, self-registrations disabled;
- there is an external IdP;
- generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
- in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.

Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).

My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.

Please let me know if you think it's worth having this in Keycloak. Regards,
Dmitry


From bruno at abstractj.org  Thu Mar 28 14:56:22 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 28 Mar 2019 15:56:22 -0300
Subject: [keycloak-dev] Application Initiated Actions Draft #2
In-Reply-To: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
References: <CAJgngAdDbTVEMXTp1ZaK6o0GqpBMy3M0HMMzJd605DoEofehOQ@mail.gmail.com>
Message-ID: <20190328185622.GA19720@abstractj.org>

Great stuff, I really liked the second version.

+1

On 2019-03-28, Stian Thorgersen wrote:
> Based on feedback and also thinking about this a bit more I've now updated
> the proposal for Application Initiated Actions.
> 
> Please read and comment on the update draft if you're interested.
> 
> https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From kedar.maindargikar at gmail.com  Sun Mar 31 03:48:59 2019
From: kedar.maindargikar at gmail.com (Kedar Maindargikar)
Date: Sun, 31 Mar 2019 13:18:59 +0530
Subject: [keycloak-dev] keycloak with postgres database
Message-ID: <CAKzTivbUPxr-1xFymTz0iBjphfKKa0TThMxpSZU3P_wq7wVsRg@mail.gmail.com>

Hello,

I am new to keycloak , I would like to understand if I am using keycloak in
"standalone cluster mode" where each node will have a copy of keycloak
running which connects to external postgres database.,  where the postgres
nodes are not in cluster but have one to one connection with key cloak
deployment on each node .

Will this work ?

Thx
Kedar

From sguilhen at redhat.com  Sun Mar 31 18:33:20 2019
From: sguilhen at redhat.com (Stefan Guilhen)
Date: Sun, 31 Mar 2019 19:33:20 -0300
Subject: [keycloak-dev] keycloak with postgres database
In-Reply-To: <CAKzTivbUPxr-1xFymTz0iBjphfKKa0TThMxpSZU3P_wq7wVsRg@mail.gmail.com>
References: <CAKzTivbUPxr-1xFymTz0iBjphfKKa0TThMxpSZU3P_wq7wVsRg@mail.gmail.com>
Message-ID: <CA+7ohf=n3O7H4vUSauLKKFThkjPRASmM0AyX0HDobuL9TrR1UQ@mail.gmail.com>

Hi Kedar,

For user related questions please refer to the keycloak-user mailing list.
This list is for discussions about the development of Keycloak.

Best regards,

On Sun, Mar 31, 2019, 04:51 Kedar Maindargikar <kedar.maindargikar at gmail.com>
wrote:

> Hello,
>
> I am new to keycloak , I would like to understand if I am using keycloak in
> "standalone cluster mode" where each node will have a copy of keycloak
> running which connects to external postgres database.,  where the postgres
> nodes are not in cluster but have one to one connection with key cloak
> deployment on each node .
>
> Will this work ?
>
> Thx
> Kedar
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>