Application Initiated Actions
by Stian Thorgersen
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).
7 years, 1 month
SAML attribute to session attribute mapper
by Brandon Suzuki
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(a)amplify.com
Amplify
55 Washington Street, 8th floor
Brooklyn, NY 11201-1071
amplify.com <http://www.amplify.com/>
7 years, 1 month
Reset Password does not give feedback on success
by Ken Haendel
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
7 years, 1 month
Microservice-oriented Integration Testing
by Tomas Kyjovsky
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/1PbsSfU8R6CEz4yYCm6Mld1pMNXxeb19JE...
[2] http://arquillian.org/arquillian-cube/
[3] https://www.seleniumhq.org/docs/07_selenium_grid.jsp
[4] https://github.com/SeleniumHQ/docker-selenium
7 years, 1 month
Implementation of OAuth 2.0 Device Authorization Grant
by Hiroyuki Wada
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(a)nri.co.jp
7 years, 1 month
Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension
by 中村雄一 / NAKAMURA，YUUICHI
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(a)redhat.com>
Sent: Monday, March 18, 2019 5:49 PM
To: 中村雄一 / NAKAMURA，YUUICHI <yuichi.nakamura.fe(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>; 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com>; 茂木昂士 / MOGI，TAKASHI <takashi.mogi.ep(a)hitachi.com>; Yoshikazu Nojima <mail(a)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@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@redhat.com>
Sent: Thursday, February 28, 2019 6:53 PM
To: 中村雄一 / NAKAMURA，YUUICHI <mailto:yuichi.nakamura.fe@hitachi.com>
Cc: keycloak-dev <mailto:keycloak-dev@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@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@lists.jboss.org <mailto:mailto:keycloak-dev-bounces@lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:mailto:keycloak-dev@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%2...
_______________________________________________
keycloak-dev mailing list
mailto:mailto:keycloak-dev@lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2...
7 years, 1 month
Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension
by 中村雄一 / NAKAMURA，YUUICHI
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(a)redhat.com>
Sent: Thursday, February 28, 2019 6:53 PM
To: 中村雄一 / NAKAMURA，YUUICHI <yuichi.nakamura.fe(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)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@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@lists.jboss.org <mailto:keycloak-dev-bounces@lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:keycloak-dev@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%2...
_______________________________________________
keycloak-dev mailing list
mailto:keycloak-dev@lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2...
7 years, 1 month
Changes for Quarkus Extension
by Pedro Igor Silva
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
7 years, 1 month
