Adding support for client certificate with LDAP SASL EXTERNAL
by Tero Saarni
Hi,
I'm using Keycloak with LDAP user federation. I have enabled LDAP StartTLS.
Proposal for new use case:
As an administrator, I would like Keycloak to use client certificate based
authentication instead of bind DN and bind password when Keycloak operates
as an LDAP server admin.
Simple bind (username + password) will be still used for end-user
authentication.
Background:
Currently simple bind is the only supported authentication method with
StartTLS.
LDAP with SASL supports "EXTERNAL" mechanism [1] to achieve client certificate
based authentication.
Do you think this is acceptable use case?
If you do, I would be interested to work with this and create JIRA and PR.
--
Tero
[1] https://tools.ietf.org/html/rfc4513
4 years, 5 months
Single Page to manage credentials
by Bruno Oliveira
Good afternoon,
Stan started the work here[1] to provide a single page to manage
credentials based on the New Account console feedback[2], you can have
an idea about how it looks like based on this screenshoot[3]. Please
keep in mind that this is a WIP.
Based on the mock-up[2] provided in the same document, there are some
items that we need to clarify to move forward.
1. Is this a toggle switch like (ON/OFF) for "Two-factor authentication"
or just informative to show that 2FA is turned on? If that's a toggle
should we handle this with AIA, by asking the user to re-authenticate?
Today, we don't do this.
2. Mobile Authenticator - Hamburger menu with actions like
delete/update. IMO does not make sense to provide "update" as one of the
actions. Maybe delete and view to display all the devices enrolled.
3. Backup codes. Are we going to provide this? I'd say no, but it's
better to confirm.
4. Additional two-factor authenticators. At the moment we don't have any
way to use SMS, so I assume we're going to remove this. It seems to me
that the Web Authentication section overlaps with the "Passwordless"
section, but I can be wrong. Maybe we should choose which one we would
like to keep to avoid confusion?
5. Passwordless section. Is the ON/OFF informative or a toggle switch
between both states?
6. Passwordless/Web Authentication. As I mentioned before, it seems to
me as an overlap. But I can be wrong.
Another thing that I was thinking for "Web Authentication" is to show an
hamburger menu with (Set up/View/Remove) instead of just "Set up".
Any thoughts?
[1] - https://github.com/keycloak/keycloak/pull/6516
[2] - https://i.imgur.com/UWn3mch.png
[3] - https://i.imgur.com/1RKwx4A.png
--
abstractj
4 years, 5 months
Authentication flows - follow-up tasks and usability improvements
by Marek Posolda
Based on the discussion within Keycloak team and with CloudTrust team
and also based on the other facts, there are still quite a few follow-up
tasks regarding usability and further improvements. It will be good to
clarify the priorities of the follow-up tasks and also how exactly to
address them. Regarding usability, it will be nice to receive feedback,
so we're on the same page how screens should look like.
1) Improvement for end-user during authentication in regards to select
alternative credential for authentication. This is something, which we
discussed within the Keycloak team. The idea is to provide users the
same/similar screens like Google does. We are a bit more constrained as
Google doesn't allow administrators to have custom authentication flows
and hence doesn't need to care too much about various corner cases. So
not sure if we can achieve same usability for all the possible
authentication flow configurations. But we probably have a space for
improvement here.
I've created google docs
https://docs.google.com/presentation/d/13PpcT26WPTC7v34hS6rj8U63xyZx4lZrP...
with some example scenarios how could authentication of end user looks
like for particular authentication flow configuration and for particular
set of credentials available to target user. Comments should be allowed
to anyone, so feel free to comment here or in the docs. Also if you have
idea for some more use-cases to cover, feel free to write here.
IMO this looks like quite a priority as it affects end-users usability
and hence will be nice to have this before February?
2) More flexibility around conditional authenticators
Some basic ideas, which we discussed within Keycloak team around
conditional authenticators are:
- Ability that each condition is able to "vote" rather than have
requirements on conditional executions. It could be something similar to
authorization policies available in Keycloak authorization services.
- Ability to compound conditions based on "AND" / "OR" logical
conditions. For example allow easily to configure that particular
subflow will be triggered if (condition1 == true || (condition2 == true
&& condition3 == true)
- Ability to configure conditions. For example ability to have
positive/negative logic for RoleCondition similarly like RolePolicy in
authorization services has.
- Ability to integrate with the 3rd party engine for adaptive authentication
- Ability for administrators to clearly see how conditions are
evaluated. Ideally have same/similar level of flexibility like
Authorization policies have
I can try to do some more concrete proposal with example of screens,
hopefully later this week. If anyone wants to start on some proposal
around this before, feel free to go. IMO this is something, which
doesn't have so big priority like (1) as it doesn't affect end users.
The question is, whether to postpone improvements around conditions to
later next year when we start on step-up authentication (which will
require good flexibility around conditions and hence should help to
naturally address this)
3) Usability improvements in the admin console in the "Authentication
flows" screen. The plan is to rewrite admin console in the future and
improve on various screens, however until that is done, we can probably
improve usability a bit even in the current admin console to make the
things slightly more friendly for the administrators. I consider those
things a low hanging fruits in comparison to (2) and hence hopefully
doable before February.
https://issues.jboss.org/browse/KEYCLOAK-12013 Hide the subflows if the
parent flow is disabled
https://issues.jboss.org/browse/KEYCLOAK-11968 Ensure that REQUIRED and
ALTERNATIVE executions are not mixed at same level. ALTERNATIVE
executions are defacto ignored/disabled when they are used together with
REQUIRED executions, hence it will be nice if admin is aware of that and
won't have possibility to configure ALTERNATIVE at same level as
REQUIRED (or at least is WARNED somehow that this configuration doesn't
makes sense and ALTERNATIVES will be ignored).
https://issues.jboss.org/browse/KEYCLOAK-11824 When authentication
execution is added, we should make sure that some REQUIREMENT is
selected by default
https://issues.jboss.org/browse/KEYCLOAK-11969 Hide the conditional
authenticator if it is configured outside of conditional flow. This JIRA
is related to the conditional executions and hence I am not sure whether
to address it together with other improvements related to conditional
authenticators. However it is low hanging fruit in comparison to (2), so
probably doable.
4) Other usability improvements. Similarly like (3), those are low
hanging fruits and likely doable before February.
https://issues.jboss.org/browse/KEYCLOAK-12011 Remove cancel button from
OTP form. IMO it will be better for usability if "Cancel" button is
removed from the OTP form. Form already has the "Back" button, which
provides more flexiblity. This is a bit related to the topic (1). WDYT?
https://issues.jboss.org/browse/KEYCLOAK-11922 Apply password history
policy when password reset by admin. After applying multi-factor
prototype, the password history policy is not applied when password
reset by admin. It is applied just in case when it is reset by user
himself. IMO this behaviour is fine and can even have better security
(The case when admin randomly guess the password of some user can cause
admin to be tempted to try this password against some other web
application and authenticate as that user). Any preference on the behaviour?
Thanks for the feedback,
Marek
4 years, 5 months
[Keycloak Operator] Builder image
by Sebastian Laskawiec
Greetings!
When we were working on Keycloak Operator, we introduced a hacky solution
for building our image [1]. It uses a shell script to build the binaries
[2], which turned out to be problematic in Quay due reusing build cache
[3]. This resulted in our builds containing old binaries, which was
critical to fix. We found a workaround but I wanted to revisit this issue
with something better...
In Pull Request #96 [4] I came up with a solution that uses Docker
Multi-Stage builds. In short - the build is divided into 2 stages. The
first one creates a container that builds our binaries (so called a builder
container) and then we copy them (the binaries) to the final container. The
whole point is that the final container doesn't need to contain Golang,
Make or any other things necessary to build binaries.
This approach has the following advantages:
- It makes the image smaller - from ~250 MB to ~54 MB (see [5][6]).
- It's just a pure UBI8 image with zero other dependencies, which means
smaller CVE surface.
- This approach fixes operator-hub build command.
- It allows to play with build cache using --cache-from (so that you can
reuse previous build results and modify only the final image).
However, there are some drawbacks as well:
- Say bye bye to Docker 1.13 (which is installed by default on Fedora OS).
Multi-stage builds require newer Docker version or Podman [*].
- Dockerfile had to be moved to project's root. As the build process pulls
local files (cloned by git), so everything needs to be in the Docker
context. The easiest (and most stable) way to achieve this is to put the
Dockerfile into the root.
- In order to get `operator-sdk build` command fixed, I had to create a
symbolic link (of the Dockerfile) in the build directory.
Even though, this solution is not aligned with other Keycloak projects, I
believe that's the right approach. Afterall, with the shell scripts
approach we're simulating this behavior having a proper solution at hand. I
would highly encourage (and advise) adopting this approach to other
Keycloak images (such as Gatekeeper or maybe even Server).
If you don't like this solution - I prepared a workaround that fixes our
build here [7]. It's much less elegant and frankly, I don't like it.
Thanks,
Sebastian
[*] I like Peter's trick for this - he created an alias for `docker`
command pointing to `podman` !!!
[1]
https://github.com/keycloak/keycloak-operator/blob/master/build/Dockerfile
[2]
https://github.com/keycloak/keycloak-operator/blob/master/build/Dockerfil...
[3] https://github.com/containers/buildah/issues/1906
[4] https://github.com/keycloak/keycloak-operator/pull/96
[5] https://quay.io/repository/slaskawi/keycloak-operator-private?tab=tags
[6] https://quay.io/repository/keycloak/keycloak-operator?tab=tags
[7] https://github.com/keycloak/keycloak-operator/pull/97
4 years, 5 months
CORS origin check in java adapter - PreAuthActionsHandler
by Skorupa, Sascha
Hello,
is there a reason why origins aren't configurable via deployment to be checked in PreAuthActionsHandler in the Java Adapter? The preflightCors() method performs checks against methods and headers, but all origins seems to be accepted.
Sascha
4 years, 5 months
Usability: Improve screen for setup TOTP
by Marek Posolda
I want to ask some feedback about the screen for the "Setup TOTP" . I've
created JIRA https://issues.jboss.org/browse/KEYCLOAK-12168 , which
contains some screenshot of how currently the screen for the required
action for "Setup OTP" looks like. In other words, this is displayed to
the user at the end of the authentication when he has "Setup TOTP"
required action on him.
Few questions:
* Is the "Device name" appropriate label? Would something like
"Authenticator App Label" be better?
* Should it be more emphasized that "Authenticator App Label" is not
mandatory? IMO it is currently not very clear. Also there is nothing
in the help-text about this input field. Maybe we can add another
sentence to point 3 like "Optionally provide Authenticator App Label
as a reference." I am not very happy with that sentence. Any better
ideas?
* Alternatively we can use separate screen for providing the
"Authenticator App Label" . In other words, there will be just
single input for OTP code and than once user clicks "Submit" and OTP
code is successfully verified, there will be another screen where he
can provide "Authenticator App Label" . It seems Google is using
separate screen for providing labels when user register Security Key.
* Any better ideas?
* We can possibly improve the old account console in similar manner.
Currently it looks like in screenshot setup-otp-account-mgmt.png .
Maybe we can at least change the label for "Device name" and also
add another sentence to the help text?
Thanks,
Marek
4 years, 5 months
WebAuthn: next plans
by Marek Posolda
The WebAuthn authentication is available in Keycloak since the last 8.0
release. We have plans to do some improvements around it like:
- Allow WebAuthn to be used as 1st-factor and 2nd-factor - It seems that
WebAuthn is the kind of credential, which is often used as both
2nd-factor or passwordless. This is not the case for some other common
credentials - for example password is usually used as 1st-factor when
OTP is usually used as 2nd-factor. We discussed within Keycloak team
that we want to allow users/administrators to be able to use WebAuthn as
both 1st-factor and 2nd-factor even within single authentication flow.
To achieve this, we want the ability to have 2 WebAuthn configurations
(WebAuthn policies) within the realm - one for passwordless and one for
2-factor authentication. Because of some limitations in current
framework, we will also temporarily duplicate some java classes
(Authenticator, RequiredAction, CredentialProvider etc) to be able to
differentiate between WebAuthn passwordless and 2nd-factor. This will be
improved in the future, but so far, priority is to improve experience
for the end user, so workaround of duplicating classes may be fine. Some
details in the JIRA https://issues.jboss.org/browse/KEYCLOAK-12174 .
- Improving usability of WebAuthn authentication: So far we discussed
that when WebAuthn authentication form is displayed, there won't be
checkboxes with available WebAuthn authenticators, but instead all the
registered WebAuthn authenticators of particular user (and particular
factor according to if we're authenticating as 1st-factor or 2nd-factor)
will be tried. This will allow that there is no need to explicit submit
via "Login", but WebAuthn authentication will be tried immediately when
the WebAuthn authentication form is displayed. We want the ability for
user to retry authentication or eventually go back and "try another way"
to authenticate (for example via OTP if user has both OTP and WebAuthn
as alternatives of 2nd-factor authentication). More details in the JIRA
https://issues.jboss.org/browse/KEYCLOAK-12177 .
If you have any feedback, feel free to comment.
Thanks,
Marek
4 years, 5 months
Granularity of roles in account endpoint
by Douglas Palmer
In the commit 0ce10a3249db69592cb7fee70cefd4a2eec66423, three new AccountRoles were added:
view-applications
view-consent
manage-consent
Do we need/want such fine grain access control? Or should we stick with just using manage-account and view-profile?
Regards
Doug
4 years, 5 months
