authenticating applications
by Bill Burke
If SSL is a realm requirement, can't you use two-way SSL using between
Keycloak and the application's server using the certificates of each of
those servers? There would be no need to set up client certs. For
self-signed certs you could even do what the browser does and have the
admin console ask to trust the cert from the host of the application's
server (vice versa too!).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
Quick Question Regarding the WildFly Demo
by Clifton Lee
Hello, I'd post this on the users list but there didn't seem to any
activity there.
After downloading the keycloak-appliance-dist-all-1.0-alpha-1.zip file,
configuring the portal & customer portals, I received the following
error when trying to authenticate: failed to turn code into token.
I used a different password from the demo but I made sure to keep the
password consistent with the KeyCloak server and the portal servlets.
Has anyone come across this? Thanks.
*******************************************************************************
The views, opinions, and judgments expressed in this message are solely those of the author. The message contents have not been reviewed or approved by the UFT Welfare Fund.
*******************************************************************************
11 years, 11 months
Theme support for forms
by Stian Thorgersen
As forms and the account management console are aimed at end-users it's important that it's easy for developers to customize the look and feel of these so they integrate well with their organizations and applications.
This is one of the main reasons we're using a template engine instead of a web framework. We've chosen FreeMarker as it seems to be relatively popular, is powerful and at the same time has a relatively low learning curve.
For the next release I'm going to add support for themes to the forms. As part of this I'd like to split the forms (login, registration, etc.) and account management into two separate maven modules. Initially I'll focus on adding theme support for the forms, but shouldn't be a problem to add support for both in the next release.
A theme will consist of:
* theme.properties - standard java properties file with theme name, name of theme it extends, etc. Can also contain theme specific config options
* css
* images
* messages
* pages
A theme can extend another theme, in which case it can override specific resources in the theme. For example a theme could consist of nothing but "theme.properties" and "css/styles.css". In fact this will be the recommended approach as in most cases it should be possible to do the required customization using css (anyone that doubt's this can have a look at http://www.csszengarden.com/ to see what can be achieved with css).
If needed a theme can override pages as well, this will be html pages with the addition of FreeMarker syntax. All pages can be overridden, or just individual pages.
A theme can be packaged as a ZIP, then copied into a specific directory or uploaded through the admin console. It will also be possible to package a theme as a JAR and add as a dependency, in which case we'll use ServiceLoader to discover themes on the class-path (this is how the default theme will be packaged to make sure it's easily available).
There will also be an SPI to allow replacing FreeMarker with whatever you want. We'll provide one implementation which is what's described above. This will probably be left for later though.
Finally, through the admin console it will be possible to set what theme to use for a realm. Initially this will only be setting the theme name, but in the future we may also support configuring theme properties. The default theme when creating a new realm will be the Keycloak theme.
11 years, 11 months
Password resetting
by Stian Thorgersen
To prevent hijacking the thread for planning what goes into the next release, I'll start this new thread on this subject.
For clarification, at the moment what we have with password reset is :
Users:
* If realm allows it and user has registered email address they can click on the recover password option. They then insert their username and an email with a link is sent to them. This link will expire within a configurable time (default is 10 min I think). The link will open a form enabling the user to insert a new password.
Admins:
* Admins can set a new temporary password on a user account. This will add a flag that the user is required to reset the password on next login. Currently the admin could remove this required action though, as admins can add/remove required actions to an account
Improvements to this flow would be good. It's not elegant that admin has to manually create tmp password, and somehow communicate this to the user. Also, as Bruno pointed out this would mean an admin could gain access to a users account. Any other concerns?
With regards to admins being able to send recover email, I'm not sure I see the point. Users can do this themselves if they want to. Also, the link in the email expires within a relatively short timeout, so it would quite likely be expired by the time a user reads it
Stopping a compromised admin being able to access the account, I'm not sure that would be feasible. Even if an admin can't set a tmp password, they could for example change the email and get a recovery password email sent to themselves. I also think a compromised admin account would mean we're pretty screwed in any case, so is this really important?
I don't understand how TOTP would work, can you explain.
11 years, 11 months
priorities and who is available?
by Bill Burke
I'd like to do another release in February. Let's get an idea on
available resources, what the priority are, and who can work on what.
Let's see what work we can do in parallel.
Key functionality:
* Get Stan's Wildfly subsystem incorporated.
* Figure out appropriate addition to admin console for Stan's subsystem.
An SPI or something as well as UI.
* Composite Roles.
* Clean up Forgot Password and Reset password. Should be possible for
admin to send user an email with a URL that allows them to reset the
password. Right now requires entering in a password, telling user, and
sending an email.
* Password Policies are broken.
* Revocation policies.
* Storage protection. Smarter password hashes and protection of private
keys and OTP keys.
* User session management. Be able to show and list users logged into
an app and be able to remotely logout one or all of them.
* More CORS options at the adapter level.
* Device mgmt and security. Need input from Bruno.
Basically, we should have laser focus on critical features that must be
implemented to have a functional Keycloak release, but also to support
the needs of Red Hat projects specifically LiveOak, Wildfly, and
Aerogear. Having Keycloak drive security for those 3 projects will get
us a lot more users than if we just went at it alone.
Personally, I'd like to get Stan's work incorporated as soon as possible
and figure out a UI around it. We should brainstorm together, but I
think we may have to rethink some of our UI.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
Password storage and KDFs
by Bruno Oliveira
Good morning guys, as a suggestion to improve the way how the passwords have been stored in nowadays I did some changes to support PBKDF2[1] (we have been doing the same thing on AeroGear for mobile devices), into this way is possible to prevent rainbow tables and brute force attacks like HashCat does for example.
I'm completely fine on adding bcrypt as long as we include some KDF, I just didn't that because I would like to hear some feedback before move forward, not sure if makes sense but my suggestion is to remove SHA-* encoders because they can be easily broken and replace by the support for PBKDF2 and bcrypt only.
What do you think? Let me know if I should move forward or that doesn't fit.
[1] - https://github.com/keycloak/keycloak/pull/171
--
abstractj
11 years, 11 months
