Merry Christmas from the Keycloak team
by Stian Thorgersen
2014 was the year of Keycloak! At least that was the case for us on the Keycloak team. In January we released the very first alpha of the project. The first stable release wasn’t out until September, but in return we added a lot more features as well as reaching a very high level of stability for a 1.0.
Since then we’ve delivered a number of security and bug fixes for 1.0, while continuing to bake in new exiting features for 1.1. We’re planning to do a stable release of 1.1 early in the New Year, which will bring SAML 2, much improved clustering and a number of new application adapters.
Not only have we managed to provide a feature rich and easy to use open source security solution, but we’ve also managed to build an awesome community around the project. We’ve had over 5000 downloads, over 2500 commits from 32 contributors and our developer and user mailing lists are very active. Keycloak is already in use in production on a number of projects, in fact some has even used it in production since our first alpha release!
Our road-map for 2015 is not written in stone, but expect at least some of the following features to be delivered in 2015:
* Custom user profiles – this will let you configure the attributes for a user profile, which should be visible on the registration screen and account management, as well as specify validation
* Identity Brokering – we’re adding support to authenticate with external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
* Two-Factor Authentication – currently we only support Google Authenticator or FreeOTP applications for two-factor authentication, but we plan to make it possible to add your own and provide some more out of the box
* Client Accounts – these will be special user accounts directly linked to a client, allowing a client to access services as itself not just on-behalf of users
* Client Certificates – support authentication of clients with certificates
* Client Types – at the moment we have applications and oauth clients, the main difference being oauth clients require users to grant permissions to roles. To simplify the admin console we plan to introduce a single unified view for clients and also introduce new types such as devices
* Internationalization – internationalization support for login and account management pages
* SMS – enable SMS to recover passwords, as a 2nd factor authentication mechanism and to be notified about events like login failures
* OpenID Connect Dynamic Registration – allows clients to dynamically register with Keycloak. We’ll also look at passing the OpenID Connect Interop testing
* Mapping of users and tokens – custom mapping of user profiles from external identity stores and tokens from external Identity Providers
We also have ideas for some bigger features, but we’ll leave those as a surprise for 2015!
Finally, I’d like to wish everyone a Merry Christmas and a Happy New Year.
10 years
${...} enclosure in standalone.xml
by Michael Gerber
Hi all,
I want to use ${...} enclosure in standalone.xml like the following example:
<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
<secure-deployment name="app.war">
<realm>xxx</realm>
<resource>xxx</resource>
<realm-public-key>MIGfMA0GCSqGS</realm-public-key>
<auth-server-url>https://localhost:8443/auth</auth-server-url>
<truststore>${jboss.server.config.dir}../../certs/cert.jks</truststore>
<truststore-password>password</truststore-password>
<ssl-required>ALL</ssl-required>
<credential name="secret">6e12d2db</credential>
</secure-deployment>
</subsystem>
But I've got the following error:
Caused by: java.lang.RuntimeException: org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.lang.String out of START_OBJECT token
at [Source: java.io.ByteArrayInputStream@27312e38; line: 1, column: 344] (through reference chain: org.keycloak.representations.adapters.config.AdapterConfig["truststore"])
at org.keycloak.adapters.KeycloakDeploymentBuilder.loadAdapterConfig(KeycloakDeploymentBuilder.java:102)
at org.keycloak.adapters.KeycloakDeploymentBuilder.build(KeycloakDeploymentBuilder.java:91)
at org.keycloak.adapters.undertow.KeycloakServletExtension.handleDeployment(KeycloakServletExtension.java:135)
Does anyone know how to fix this?
Thank you for your help!
Michael
10 years
sorry, we were away
by Bill Burke
Hey Keycloak community,
Sorry if we were unresponsive last week...We were in Brno for a face to
face meeting of entire team. One of us will blog about it next week
sometime.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
Keycloak 1.1.0.Beta2 released
by Bill Burke
A lot of new features this release.
Tomcat 6, 7, and 8 adapters
Jetty 8.1, 9.1, and 9.2 adapters
HTTP Security Proxy for platforms that don’t have an adapter based
on Undertow.
Wildfly subsystem for auth server. Allows you to run keycloak in
domain mode to make it easier to run in a cluster.
Hope to do 1.1.0.Final sometime end of January. See http://keycloak.org
for more details
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
blog topics
by Bill Burke
There's a bunch of different blogs/articles we could write over the next
few months to discuss/promote Keycloak and web security. Here's some ideas:
Keycloak approach to federation:
* discuss our import and sync approach
* discuss IDP federation (when Pedro gets it in).
Validating CORS requests with Keycloak:
* Discuss what CORS is and why it exists
* Discuss how Keycloak helps to manage CORS requests
Preventing CSRF:
* Discuss what CSRF is and how HTTP SEssion/cookie based security is
vulnerable
* Discuss how to mitigate with bearer tokens, CORS, and other techniques
we use for old-school web apps.
Preventing Clickjacking
* What is clickjacking.
* discuss HTTP headers that apps can pass back to prevent this.
How to brand/embed Keycloak to make it look like your product.
There's other ones we can write down the line when we get more features
in: for mobile, keycloak and the enterprise, etc...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
Re: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Beta2 released
by Bill Burke
Fixed download page to point back to sf.net
On 12/5/2014 10:59 PM, lanabe wrote:
> Congratulations!
>
> Recently I started to apply Kyecloak to my personally simple blog
> application(using WildFly 8.2.0.FInal, JSF, JAX-RS,...).
> Keycloak is very easy to use!
>
> BTW, the download page(http://keycloak.jboss.org/downloads) remains
> 1.1.0.Beta1.
> # I got the new binary at
> http://sourceforge.net/projects/keycloak/files/1.1.0.Beta2 .
>
> Thanks.
>
> Yoshimasa Tanabe
>
> On Sat, Dec 6, 2014 at 11:08 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> A lot of new features this release.
>
> Tomcat 6, 7, and 8 adapters
> Jetty 8.1, 9.1, and 9.2 adapters
> HTTP Security Proxy for platforms that don’t have an adapter based
> on Undertow.
> Wildfly subsystem for auth server. Allows you to run keycloak in
> domain mode to make it easier to run in a cluster.
>
> Hope to do 1.1.0.Final sometime end of January. See http://keycloak.org
> for more details
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
Federated Identity and Authentication Broker
by Pedro Igor Silva
Hi,
Would like to start a discussion about how to enable KC as an Authentication Broker in order to supported Chained Federation and also Identity Federation. First of all, some background about what this is all about.
Currently KeyCloak provides two basic types of authentication (correct me if I'm wrong, please):
1) Local authentication (based on some credential type enabled to a realm)
2) Social authentication
Local authentication is about authenticating the user locally using KC's own identity store. Nothing special here. And Social Authentication which allows users to choose the Social IdP they want to authenticate with. In this case, the IdP is always one of the built-in social providers supported by KC such as Facebook, Google, Twitter, Github and so forth.
When doing social, the user is automatically provisioned in KC identity store after a successful authentication. The user does not need to fill a registration form and can access the application very quickly. During the provisioning some basic information is retrieved from the social provider such as email, firstname and so forth. These are very basic information, any other information such as those related with authorization policies - eg.: roles and groups - must be defined later via KC's admin console.
Another important characteristic of social authentication is that the application receives a KC token and not the token that was issued by the social IdP during the authentication process. If the application wants to consume resources from the resource provider he was authenticated it must obtain the access token(again) by itself prior to invoke the resource provider API. Assuming all those social providers are based on oAuth 1.0 or 2.0.
That said, the Authentication Broker functionality aims to cover the same use cases but with a lot of more flexibility on how you setup identity providers(not only social ones) and the different federation protocols they may support such as SAML, OpenID, oAuth and so forth. This is useful when an enterprise is providing services to different customers(IdP) and does not want to manage many to many relationships. When using a broker, the authentication steps are pretty much the same when you are using social authentication, with important differences on how you support different identity providers, different federation protocols, how users are provisioned and how claims and attributes are resolved.
The brokering functionality can be done in two ways depending if the broker service is acting as a gateway or not. When acting as a gateway, the broker will respond to the application the same token issued by the trusted identity provider. For instance, if the user selects a SAML IdP to authenticate with, the application will receive a SAML Response. In this case, the application must also be prepared to handle a specific federation protocol.
However, the broker service can also be used to completely abstract from the application the protocol used to authenticate an user. In this case, the application will just receive an ordinary KC token after a successful authentication.
In both cases, the broker acts as an intermediary where specific security policies can be applied when users try to authenticate themselves against a 3rd party IdP. That brings a lot of value when you think about auditing, authorization and how users are provisioned when federation of identities is needed. This also allows existing security infrastructures (eg.: SAML-based infrastructures) to benefit from KC's support for cloud, rest and mobile use cases.
I think this is enough to start a discussion. I've an initial discussion with Stian about all that and we agreed that abstract the protocol from applications should be prioritized. The main reason is that it makes life easier for applications so they only need to know about KC tokens and nothing else. However that brings some new requirements around user provisioning and claim/attribute resolution or mapping. But that would be another thread.
I've already started something related to this. My initial work is about supporting custom SAML and OpenID IdPs. Right now I'm using a PicketLink SAML IdP, Google OIDC and SalesForce OIDC. I'm still gathering what we need in terms of configuration. But the idea is a single protocol implementation to be able to manage different IdP instances. For instance, the "social providers" would be just OOTB implementations for all those common social networks. From an initial discussion with Stian we agreed that we should keep the "Social Authentication" concept for the sake of users. However, internally we would need to refactor the Social SPI in order to decouple oAuth2 from it and support other protocols such as SAML.
That said, the first thing would be change the Social SPI without introduce any new functionality. But prepare it to support the next feature set.
Any thoughts ?
Regards.
Pedro Igor
10 years
vision vs. infinite configurability
by Bill Burke
Users want Keycloak to work like their existing solutions. Users have
peculiar use cases they need to solve. As engineers, we want to satisfy
our customer's needs so we add option after option.
This worries me...
We have to constantly think about the Keycloak "vision". We need to
continually think about how users *should* use Keycloak rather than how
they want to use it. Every time we add a new configuration option to
keycloak we add complexity. We make keycloak harder to understand and
use. We need to keep this in mind as we go forward over the next few
months. When customers ask for a new feature we need to ask them or think:
* Is there an existing way to do this?
* Should we allow this option?
* Is there a better way to solve the customer's need?
A big one is: Can we enforce specify policies to make Keycloak easier to
configure? For example, as a SAML IDP, we can say, sorry, but any SP
needs to be able to handle signed saml documets. we don't need to
provide the config switch to not sign a document. Get what I mean?
BTW, this is why I get so pissy whenever you guys want to add another
SPI or config switch. I know how these types of things snowball as a
project ages. You can collapse under the weight of them. Having a
"vision" helps tremendously as you tell users how they should be doing
security rather than just doing whatever they want.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
