Support for conditional AuthenticationFlowExecution.
by Thomas Darimont
Hello group,
this is my first post on this mailinglist and I want to say thank you for
this awesome project!
I had a look at many IDM / SSO solutions before and Keycloak provided the
best out-of-the box
experience so far!
I posted the following in the JIRA initially but Stian Thorgersen asked me
to post this
on the mailing list as well.
Scenario:
Support for conditional AuthenticationFlowExecution.
Often some authentication flow steps should only be executed under certain
conditions,
e.g. somtimes a TOTP based auth step is only required of requests come with
a
certain request header value.
It would be cool if one could configure a condition on the
AuthenticationFlowExecution
(if I'm not mistaken) that if evaluated to true would execute or skip a
particular authentication step.
This could perhaps be configured via the admin console in the
Authentication -> Flows tab.
Conditions could perhaps be simple JavaScript expressions that could be
evaluated via the built-in JavaScript ScriptEngine.
For this it would be useful to provide a set of "standard" functions that
can be called from the expressions (perhaps based on a whitelist).
Admins should also be able to define their custom functions.
The context could provide access to the current http request, current user,
the requested client application and perhaps the keycloak configuration.
The issue: https://issues.jboss.org/browse/KEYCLOAK-2108
10 years, 10 months
changing adapter error handling
by Bill Burke
Any servlet based adapter will now be using
HttpServletResponse.sendError with the appropriate Http status code of
the protocol. To handle errors, users will have to add the appropriate
error code handlers in web.xml. I should have done that in the first
place, but quite honestly, I didn't even know that existed in the
servlet spec.
I'll be setting a request attribute that contains a protocol specific
object so that people can view the error code, message, or anything else
the protocol provides (i.e. SAML errors can be quite complex and can
have their own document).
Hopefully I"ll have this done by tomorrow.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Identity Broker login flow
by Dane Barentine
Hi all,
I'm trying to add a custom authenticator and it appears that that there is no way to insert it in the flow if it's a brokered IDP login where the linked Keycloak account already exists.
If it's a local Keycloak user I can use the Browser flow and if it's a new brokered user the First Broker Login flow will execute. But I don't see a flow that would allow me to insert something like OTP after a brokered login of an existing user.
If I'm just missing it let me know but I think there needs to be some sort of flow for brokered logins that runs on both existing and new users. For new users it would run after the First Broker Login flow. Or better yet maybe a flow that would allow things such as OTP to happen after any brokered or local login. That way it wouldn't have to be configured in multiple flows.
Thanks
Dane
10 years, 10 months
Client ID and Client ClientID - I propose we remove one
by Stian Thorgersen
We have both "id" and "client-id" for clients in Keycloak at the moment.
This seems unnecessary and complex.
The model can retrieve clients on either value. In token endpoints the
"client-id" is used. In admin endpoints the "id" is used.
Also, in most cases it would be simpler for users to just have a generated
id than having to come up with one themselves. The id doesn't have to be
human readable either as we have name for that.
OpenID Connect expects "client-id" to be generated by the IdP and can't be
changed once created.
I propose we remove "client-id" and only keep id.
For migration of existing clients we would set the "id" value to the
current value of "client-id". This would require no changes to adapter
configs. When creating new clients from the admin console we would not
allow setting the "client-id", instead just display it after the client was
created. When importing clients it would be possible to set the id (and for
backwards compatibility we would set "id" equal to the "client-id" field.
10 years, 10 months
Re: no empty password in UserFederationProvider
by Michael Gerber
AbstractUsernameFormAuthenticator.validatePassword
public boolean validatePassword(AuthenticationFlowContext context, UserModel user, MultivaluedMap<String, String> inputData) {
List<UserCredentialModel> credentials = new LinkedList<>();
String password = inputData.getFirst(CredentialRepresentation.PASSWORD);
if (password == null || password.isEmpty()) {
invalidPassword(context, user);
return false;
}
credentials.add(UserCredentialModel.password(password));
boolean valid = context.getSession().users().validCredentials(context.getRealm(), user, credentials);
if (!valid) {
invalidPassword(context, user);
return false;
}
return true;
}
I think we can remove the first if (password == null || password.isEmpty())
Am 20. November 2015 um 16:11 schrieb Bill Burke <bburke(a)redhat.com>:
Point me to the code?
On 11/20/2015 9:04 AM, Michael Gerber wrote:
Hi All,
keycloak does not pass an empty password to the validCredentials method
in the UserFederationProvider class.
Is there a reason for that? I would like to authenticate against an AD
even if the password is empty, otherwise the user won't be blocked after
x attempts.
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10 years, 10 months
groups in
by Bill Burke
* Groups are hierarchical. One parent, multiple children. UI is a
tree. Probably needs some UIX love. I couldn't get a drag-drop Tree
widget working...As a result, you have to use a combination of button
presses to add a group to a parent. (new/cut/paste)
* Attribute and Role mappers will now take group membership into account
when mapping tokens and SAML assertions.
* Default Groups added. Same as Default Roles, accept for groups.
* There are new GroupMappers added to SAML and OIDC mappers. They are
not on by default.
This work probably should have been done a week or two ago, but oh
well...I'm inefficient lately...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 11 months
no empty password in UserFederationProvider
by Michael Gerber
Hi All,
keycloak does not pass an empty password to the validCredentials method in the UserFederationProvider class.
Is there a reason for that? I would like to authenticate against an AD even if the password is empty, otherwise the user won't be blocked after x attempts.
Michael
10 years, 11 months
Change few methods on UserFederationProvider
by Marek Posolda
Currently we have those methods on UserFederationProvider:
boolean validCredentials(RealmModel realm, UserModel user,
List<UserCredentialModel> input);
boolean validCredentials(RealmModel realm, UserModel user,
UserCredentialModel... input);
I propose if we can:
1) Remove the second one as it's not used from anywhere .
2) Change the signature of first one to return
"CredentialValidationOutput" instead of boolean. This will allow
federationProvider to send some additional state related to
authentication instead of just true/false .
The main reason is the https://issues.jboss.org/browse/KEYCLOAK-1744 .
Basically ActiveDirectory throws exception with different code if
password provided by user is incorrect or if the password is correct,
but expired. For writable LDAP, it's fine. If password is expired, we
can authenticate user, but put requiredAction for UPDATE_PASSWORD on him.
However for read-only LDAP, we can't update password from Keycloak. In
this case, it will be nice if we can show the message in UI like "Your
password has expired. Contact your administrator to change password" .
But that's possible if we send some additional state about the reason of
failure, so Authenticator can read it and possibly display various
messages based on that.
IMO will be cool to have solution for
https://issues.jboss.org/browse/KEYCLOAK-1744 available in Keycloak out
of the box. There are lot of people using ActiveDirectory and asking for
this.
WDYT?
Marek
10 years, 11 months
Keycloak 1.7 CR1 release update
by Stian Thorgersen
Keycloak 1.7 CR1 is scheduled to be released on 2nd December (Wed). I'd
like everything to be done by end of 30th November (Mon). Then we'll do
some testing on Tuesday.
Unless any major issues are reported Keycloak 1.7 Final will be released
the following week.
For releases in the future we'll aim for the following:
* Complete work by end of Monday
* Test on Tuesday
* Release CR1 on Wednesday (Friday at the latest)
* New CR release ASAP as major issues are fixed
* Release Final one week after last CR
10 years, 11 months
