restart the authentication flow after a timeout error
by Michael Gerber
Hi all,
I am using a client with urn:ietf:wg:oauth:2.0:oob.
If a user has too long to change his password, he will retrieve an error message. However, he can not restart the authentication process.
As far as I understand the verifyAction method in the LoginActionsService, only the "authentication" action will reset the authentication flow. I think it would make sense to reset the authentication flow also if a user has too long to change his password or so.
What do you think?
Michael
10 years, 1 month
Admin console doesn't reload messages at runtime
by Stian Thorgersen
The admin console doesn't currently reload messages at runtime. This just
doesn't work for development as you have to reload the server each time to
get new messages.
Any caching of messages (or theme resources in general) should be added
to ExtendingThemeManager and made available to all uses of a
theme. ExtendingThemeManager already has some caching capability and it's
configurable so can be disabled during development.
Caching of message bundles would actually be much more important to have
for login screens than for the admin console.
For now I'm removing AdminMessagesLoader and I'll add caching to
ExtendingThemeManager soon.
10 years, 1 month
Preferred way to make KeyCloak custom changes
by Erik Mulder
Hi everybody,
Quick intro: I'm part of a development team in The Netherlands that is building a company-wide SSO solution. We've chosen KeyCloak to realize this and will use OpenID Connect to secure our REST services. It's a great product and seems to be the only one having both support for all kinds of security standards and a model and GUI for users and roles. Thanks for creating it! :)
(if this should be asked instead on the users mailing list, please correct me and I'll post it there)
So far, so good, but we have some extra requirements that do not fit into the base KeyCloak data model. See below for details if you're interested. My question is: what is the preferred way / best practice to extend the functionality of KeyCloak while keeping the impact on the original sources to a minimum? Of course we could just fork the most recent version and start hacking away, but we'd like to be able to upgrade to newer versions of KeyCloak without too much hassle. Possibilities that we've come up with so far:
1. Create completely separate modules that will extend the functionality the way we need.
2. Fork on Github, apply custom changes, and try to merge in updates from the master / release branches / tags
3. Apply custom changes on KeyCloak artifacts using a Maven plugin, such as Truezip (http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html) - manipulate zip files by adding/removing/replacing or Shade (http://maven.apache.org/plugins/maven-shade-plugin/) - combine multiple jars to 1 'uber-jar' containing the contents of both and when overlapping decide on conflicts through configuration.
Of course number 1 is preferred, but I do not see how to add custom mappers or JPA entities without making changes in the original module files. The other options seem like valid alternatives, but maybe there is better / standard way to do this. So any help / insight / shared experience on this is much appreciated, thanks!
Kind regards,
Erik Mulder
Senior Software Engineer
Docdata Payments - NL
P.S. Details on why we want to extend the KeyCloak data model: (any feedback on the contents of this P.S. is also welcome!)
Our clients are merchants that have several webshops. We manage their online payments (shopping cart checkout). We want to be able to let a merchant manage their own users and let a user have different roles for different webshops within the same merchant. The overall possible roles are fixed though, no specific roles per merchant. We could create a separate realm for every merchant, but then we need to duplicate all roles every time. Furthermore, in KeyCloak there is no concept of a role within a certain context. This is very understandable, since every situation has it's own requirements. We did a proof of concept by adding tables and entities for Merchant, UserMerchant, UserMerchantRole etc. and adding a custom mapper that can put this information on the Access token. Worked like a charm! But it does need some changes in the KeyCloak modules and sources to work, hence the question above.
10 years, 1 month
changes to browser-based flows
by Bill Burke
FYI: Not important if you are uninterested in design.
Prior to my last commit if you hit the browser refresh button you would
either have had the authentication flow completely reset or received an
error page. Also, changing the local on some required actions pages
would end up in an error condition.
So...To fix this I made some changes to browser based flows:
* After any successful action processing (i.e. a form POST), the browser
is sent a 302 redirect to a "safer" page. If you are in the
authentication phase, then this redirect will be to
/authenticate?code={code}, registration /register?code={code}, reset
credentials /reset-credentials?code={code}, required actions
/required-action?code={code}. When these URIs are executed, Keycloak
will figure out where the user is in the flow and render things
appropriately.
* After authentication, the browser will be 302 redirected to
/required-action?code={code}
The reason for these changes is to support when the user clicks the
browser refresh button. The refresh button will resubmit the previous
request. Prior to this change there were issues with this. For
example, previously, if there was a required action and you just logged
in via username and password, the URI in the browser would still point
to the username/password page even though the required action page was
being rendered. If the refresh button was hit, the previous username
password POST would be resent to the username/password page, Keycloak
would say "WTF are you doing?!?" and abort. There were similar issues
like this everywhere.
Other things effected by this fix:
* required actions no longer change the ACTION_KEY or the
ClientSessionModel.getAction().
* ClientSessionModel.getAction() will either be AUTHENTICATION,
REQUIRED_ACTIONS, EXECUTE_ACTIONS, LOGGED_OUT, or OAUTH_GRANT.
* After authentication, the flow manager will change the action from
AUTHENTICATION to REQUIRED_ACTIONS.
Overall, this is less performant as there are additional HTTP redirect
requests being thrown in, but should provide a better user experience.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 1 month
Cluster security
by Matthew Casperson
The docs state that "By default there's nothing to prevent unauthorized
nodes from joining the cluster and sending potentially malicious messages
to the cluster." (
http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering....
)
Is this still the case if the jgroups stack in Wildfly has implemented the
AUTH protocol? For example, the Openshift Wildfly config looks something
like this:
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp">
<property name="external_addr">${env.OPENSHIFT_GEAR_DNS}</property>
<property
name="external_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PROXY_PORT}</property>
<property
name="bind_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PORT}</property>
<property name="bind_addr">${env.OPENSHIFT_WILDFLY_IP}</property>
<property name="defer_client_bind_addr">true</property>
</transport>
<protocol type="TCPPING">
<property name="timeout">30000</property>
<property
name="initial_hosts">${env.OPENSHIFT_WILDFLY_CLUSTER}</property>
<property name="port_range">0</property>
<property name="num_initial_members">1</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="token_hash">SHA</property>
<property name="auth_value">${env.OPENSHIFT_SECRET_TOKEN}</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<!--protocol type="pbcast.STATE_TRANSFER"/>
<protocol type="pbcast.FLUSH"/-->
</stack>
--
*Matthew Casperson*
*Senior Front End Developer*
Technology, Space & Distribution
Auto & General Holdings Pty Ltd
P: 07) 3377 8751 (Direct: 3377 8751)
F: 07) 3377 8833
--
This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised.
If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free.
10 years, 1 month
