Keycloak Alpha 3 Released

Leave a comment

Another big feature release for Keycloak.  As usual, go to keycloak.org to find documentation and download links.  Here are the highlights of Alpha 3:

  • Minimal support for OpenID Connect.  Claims like email, full name, etc. can now be transmitted and viewed with IDToken passed after login.
  • Configurable allowed claims.  What identity claims are made in id and access tokens can be configured per application or oauth client within the admin console
  • Remote logout and session stats available from management console
  • Refresh token support
  • Not before revocation policy.  You can set it per realm, oauth client, or application.  Policies are pushed to applications that have an admin url
  • Fine grain admin console permissions and roles.  You can now specify which realms a master user is allowed to create, view, or edit.  An awesome side effect of this is that if you enable registration in the master admin realm and set a default global role of create only, keycloak can become a SaaS for SSO.
  • Installed Application feature to support non-browser applications that want to use Keycloak
  • You can now add social network links through account management

What’s next?

Our next release will be Beta-1 and will be our last big feature release.  One of the features we want to add is support for using an existing LDAP/Active Directory server.  We’re going to take a look at Picketlink IDM API for this.  We also need more fine grain support for importing and exporting various pieces of the keycloak database.  That’s minimally what we want to get in.  We’re looking at a May timeframe for this release as in April many of us will be busy with Red Hat Summit.

Keycloak SSO Released – Alpha 1

5 Comments

Keycloak is an SSO authentication server and appliance for securing web applications and RESTful web services.  After 7 months of hard work, the Keycloak team (Bill Burke, Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz) is proud to announce our first release, Alpha-1!  There’s still a lot to do, but there’s a lot you of features you can try out.  Besides written documentation, we’ve put together a bunch of video screencasts that you can view to learn and experience the features of Keycloak.

These are some of the core feature of Keycloak:

  • SSO and Single Log Out for browser applications
  • Social Broker. Enable Google, Facebook, Yahoo, Twitter social login with no code required.
  • Openshift Quick Start so you can deploy Keycloak on the cloud
  • Optional User Registration
  • Password and TOTP support (via Google Authenticator). Client cert auth coming soon.
  • Forgot password management
  • OAuth Bearer token auth for REST Services
  • Integrated Browser App to REST Service token propagation
  • OAuth Bearer token auth for REST Services
  • OAuth 2.0 Grant requests
  • CORS Support
  • CORS Web Origin management and validation
  • Completely centrally managed user and role mapping metadata. Minimal configuration at the application side
  • Admin Console for managing users, roles, role mappings, applications, user sessions, allowed CORS web origins, and OAuth clients.
  • Deployable as a WAR, appliance, or on Openshift.
  • Supports JBoss AS7, EAP 6.x, and Wildfly applications. Plans to support Node.js, RAILS, GRAILS, and other non-Java application

Go to the Keycloak website and follow the links to download, view documentation and videos, browse our source code, and submit bugs.

What’s Next?
As I said before, there’s still a lot to do, but here’s some things that will get in sooner rather than later:
  • Stan Silvert has written a Wildfly subsystem for Keycloak that didn’t get into the Alpha 1 release.  When we get this in, it will be super easy to secure web applications within a Wildfly environment.  You won’t have to crack open your WARs to add Keycloak configuration and enabling Keycloak security may be as easy as a doing a few clicks in the admin console.
  • Storage protection.  We’ll be adding support for more secure password hashing as well as storage encryption capabilities for the Keycloak database.  Its uber important to be able to have a 2nd level of defense for hacks.
  • Revocation policies. We need to be able to expire all tokens just in case somebody gets hacked and broadcast this information to deployed applications.
  • User session management.  This will allow you to view which users are logged in and give you the ability to log out one or more users.
  • Composite roles.  This will be the concept of a role group.  This will make it easier to change role mappings for a large set of users.

Thank You!

Finally, I want to give a huge thank you to everybody that helped make this release possible (Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz).  Especially Stian for being such a great co-lead and Gabriel for doing such awesome design work.  This has been the best team I’ve been on since the good old JBoss Group days years and years ago, pre-aquisition when JBoss was young.

New Keycloak Project: SSO for Browser, Social, and REST Services

4 Comments

I’d like to officially announce the new project I’m co-leading with Stian Thorgersen: Keycloak!  Some of you may already have heard hints about this on the Resteasy dev list, but since July I’ve been working with some great Red Hat guys (Stian, Gabriel, Villiam, Bolek, Alexandre, and Marek) to put together an SSO solution for browser, social, and REST service applications.  There is no release yet!  But we’re getting close to releasing our first Alpha.

Check out our screencast presentation and demo of what we got and what we’re doing:

Here’s a list of features we have or are planning to add over the coming months.

  • SSO and Single Log Out for browser applications
  • Social Broker.  Enable Google, Facebook, Yahoo, Twitter social login with no code required.
  • Optional User Registration
  • Password and TOTP support (via Google Authenticator).  Client cert auth coming soon.
  • OAuth Bearer token auth for REST Services
  • Integrated Browser App to REST Service token propagation
  • OAuth 2.0 Grant requests
  • CORS Support
  • CORS Web Origin management and validation
  • Completely centrally managed user and role mapping metadata.  Minimal configuration at the application side
  • Admin Console for managing users, roles, role mappings, applications, user sessions, allowed CORS web origins, and OAuth clients.
  • Deployable as a WAR, appliance, or an Openshift  cloud service (SaaS).
  • Supports JBoss AS7, EAP 6.x, and Wildfly applications.  Plans to support Node.js, RAILS, GRAILS, and other non-Java applications.

We would love to see anybody interested drop by on the keycloak-dev email list.  We looking to do our first alpha release sometime before Christmas.  The code was taken from the RESTEasy OAuth work I did earlier this year as well as the social broker service Stian Thorgersen and the portal team were prototyping early this year.  We’re also trying to leverage Picketlink where appropriate.

Scoping out Resteasy Skeleton Key Security

Leave a comment

I’ve been heavily prototyping a security solution for Resteasy code named Resteasy Skeleton Key. The solution has the following requirements:

  • Central auth server
  • Works with browsers.
  • Works with machine clients (code).
  • Single sign-on solution for simple web apps
  • Granting permission to third-parties to access your resources.
  • Maps well to the role-based security model of Java EE
  • Optional client certificate support for increased security
  • Supports SOA.  Distributed applications that have complex interactions between different services.
  • Cloud-ready authentication server/identity server.
  • Integrate tightly and seemlessly to JBoss AS7

 

The Implementation

You can take a look at my code as it progresses.  Here’s generally what I’m doing:

  • OAuth Bearer Token authentication for machine-based clients.
  • Bearer token will be our own extension to Json Web Token (JWT).
  • Bearer tokens will be distributed using  Json Web Signatures (JWS)
  • Bearer tokens are issued for a user and also define role allowed for each distributed resource a user might interact with.
  • OAuth 2.0 and our bearer token implementation will be used to provide browser single-sign-on.
  • Oauth 2.0 and our bearer tokens will be used to provide browser authenticated third-party access grants.  (What OAuth2 was actually designed to do).
  • Client certificates can be  required at any authentication point depending on how you configure things.  Browser to IDP, Browser to resource, client to resource.
  • Implementing an Authentication Server to support all this.

As of 11/21/2012, I have implemented a JAX-RS friendly JWS implementation.  I have speced out and implemented our bearer tokens.  I’ve written a LoginModule for AS7 that can perform OAuth2 Bearer token authentication using our bearer token format and JWS.  Token format allows you to require SSL with client-certificates.  If you have this enabled, it also supports the idea of a surrogate, that is, one principal performat a request on behalf of a specific user.  Finally, I’ve started to scope out and implement an Identity/Authentication server to support all this stuff.  This isn’t complete yet.  I’ll document this stuff in more detail as I get closer to a beta release.

 

Relationship to Picketlink

The plan is to take this prototype and eventually work with the Picketlink project somehow later on.  Either just to funnel requirements, use parts of picketlink, share code, or even have them fully take it over.  The prototype will be fully functional, but will not have many persistence options or a management UI.  There will be a REST management interface though.  Whether or not a UI is introduced will be dependent on what the relationship with Picketlink ends up being.

 

Do you really need OAuth2?

4 Comments

For those of you you didn’t know, OAuth2 has now gone to the RFC phase at IETF.  I have a lot of mixed feeling about it now that I’ve read it a few times and am starting to write code around it.  Firstly, I think the spec is very solid, well thought out, and built on top of ideas and solutions that have been around for while.  Unfortunately though, ,OAuth 2 is not a security solution in and of itself.  It isnt even a complete protocol.  It is a framework for building security protocols and solutions.  This holdstrue with frameworks stating they support OAuth2.  They can’t support Oauth2, because Oauth2 is incomplete.  Any framework with OAuth2 support will require you to write a bunch of integration code unless they are targeting a specific provider like Google or Facebook for example.

You may not need OAuth

For all the noobs writing RESTful services, they think, if I’m doing REST, I need REST security.  Given that I do REST talks every once in awhile, often I see the perception that OAuth == REST security.  So, before you say “I need OAuth”, actually understand your security needs.

  • Does your app already manage user logins and authorization?  Are your clients only going to interact with this app?  If so, you don’t need OAuth.  From the Java EE Servlet perspective,  you just need Basic, Digest, Client-Cert, or FORM authentication with user-role mapping declarations.
  • Do you *not* need the ability to grant permission to a thirdparty to access your data?  Then you don’t need OAuth

I may need OAuth

  • Do you want a central authentication server that manages authentication and authorization for all your web apps?  Then you may need OAuth
  • Do you want the allow users to grant temporary permission for third parties to access services on behalf of them?  Then you may need OAuth

Why is OAuth Incomplete?

  • OAuth2 does not define how a user authenticates.  If you are looking for OAuth to be an SSO solution, your code-driven clients will have to have specific integration with each and every auth server to pass credentials.  OAuth2 does not define what credentials should be passed around.  It does not define how those credentials are transmitted.
  • OAuth2 only suggests an app auth method.  After user authenticate, the app must turn an auth code into an access token.  OAuth2 does not require a specific authentication mechanism for this, but does require authentication.
  • OAuth2 doesn’t define the scope token or access token format.  The OAuth 2 protocol is all about acquiring a temporary access token with a defined scope.  The scope defines what a client is allowed to do. Each target service will need to understand specific scope or access token formats in order to grant specific permissions.
  • OAuth does not define how third-party authenticates.  After obtaining an access token, OAuth does not require any specific mechanism to authenticate a third-party to the target resource.  It does offer suggestions, specifically the Bearer and MAC token RFCs.

So what does this mean?  Writing generic OAuth2 support for a framework is not possible.  Users will have to implement integration code for each OAuth2-compliant auth-server they want to integrate with both on the client side of things (i.e. JAX-RS Client) or the application side (your web apps).  While it may be possible to provide some helper code, IMO, you’d be better off just coding the entire thing yourself as, IMO, you’ll understand the protocol better.

How will Resteasy support OAuth 2?

Resteasy will focus on full solutions rather than helper classes.  I’m not convinced there’s enough helper code we could write that would add enough value for users to build on top on.  Instead we’ll do the following:

  • Resteasy token formats.  We will define our own token formats that map well to JAX-RS and Java EE environments.
  • We will define specific authentication protocols for user authentication and protocols for auth code to access code conversion.
  • We will provide or own IDP/Auth-server solution.  This will be a lightweight solution with simple file-based persistence.
  • We will write specific end-to-end solutions to things like Google OAuth APIs and Picketlink and any other OAuth2 provider that is really popular
  • For each OAuth2 provider, we will have a JAX-RS only solution so you can run in any environment you want.  We will also have specific AS7 integration so you that you can use web.xml role mappings as well as Subject propagation to other Java EE component layers.

Why do client certs have to be so difficult?

8 Comments

Now that Resteasy 3.0-beta-1 is out, I’ve been thinking a lot about some custom security protocols I’d like to prototype.  Client cert authentication has always been a part of that thinking, but when it comes to browsers, client certificates are complex and even scary for most users.  Why does it have to be this way?

Current web authentication uses cookies to set up a secure session between an authenticated user and his browser.  Cookies are allocated and stored per-domain and forwared with HTTP requests to those domains.  Why can’t we do something similar with SSL and client certificates?

For example, what if when you registered at Google.com, it asked you, “Do you want to authorize this device?”.  You would click on a “OK” button and Google would generate a key-pair and a digitially google-signed certificate for your device.  The HTTP response to clicking that “OK” button would provide a base 64 encoded headers that contained the generated private key and signed certificate:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Private-Key: 23423ab1123affaccde12312
Set-Certificate: 11ab332789dff


<h1>All Set</h1>
<p>Your machine is now authorized</p>

For the google.com domain, your browser would store the private key and certificate in your browser’s persistent store.  The next time your browser makes an HTTPS connection to google.com, it would use this certificate to connect.  When you think about it, this isn’t much different than google setting a persistent cookie to remember who you are.  Now its remembering you in a much more secure way.

Additionally, what would be cool, if this google-generated client-cert could be negotiated and sent to other domains/websites on the internet.  For example, let’s say you had a social media site that exchanged sensitive information and wanted to use HTTPS.  The social media site could send a redirect, with an additional certificate negotiation header stating which client-cert domains it prefers

HTTP/1.1 307
Location: https:/.../
Accept-Certificate: google.com, facebook.com

Here, the server is redirecting us to an HTTPS based URL.  The Accept-Certificate says that it requires a google.com or facebook.com generated client certificate.  The browser would then make an SSL connection to the redirect URL using a stored client cert from one of the preferred domains.

There’s a bunch of cool things about this.  For one, you could have SSO to multiple different social media sites and applications without the need to enter one password.  Secondly, there’s a lot of secure protocols you could implement on top of this to make the internet as a whole, more secure.  Most importantly, there’s no knowledge the human user has to have as to install a client certificate.  It really sucks that the microsofts, mozillas, apples, and googles of the world haven’t put much more thought into client-certs and making them easier to use.

Decentralized Auth with Cookies

Leave a comment

Way back in June I was brainstorming about ideas for decentralized authentication.  Here’s a summary of the requirements I wanted:

  • Competely stateless servers.  Servers that host browser applications and restful services would not have to store usernames, passwords, or permission metadata (roles allowed).
  • Servers would not have to handshake with an Identity Provider (IDP).  An HTTP request should contain all the information a server needs to authenticate and authorize a client.
  • A single web request can spawn complex authenticated and authorized interactions between underlying distributed web services.  This single web request would have all the metadata needed to invoke these complex underlying interactions between distributed services.

Unifying Interactions With Cookies

The problem with the protocol discussed in my previous blog was that it relied on new headers being transmitted between the client and server.  This sort of mechanism just wouldn’t work with browser-based applications.  Why?  Well, a browser isn’t going to know how to transmit and process new headers.  The only way to get a browser to store and forward metadata is via a cookie.  Most browser-based apps already use a session cookie to authenticate users (after a log-in of course).  There’s no reason we couldn’t re-use the digital signature techniques discussed in my previous blog with cookies.  Here’s how it could work:

  1. Browser points to example.com
  2. example.com redirects browser to idp.com (the identity provider)
  3. User logins into the IDP
  4. IDP redirects back to example.com.  The forward URL has all security metadata needed for the request, digitally signed (a query parameter would have the signature).  The amazon url signing technique could be used.
  5. Example.com would authenticate and authorize based on the query parameters of the forward URL and also verify the signature.
  6. Example.com would send back a set of cookies that contained all the security metadata expressed as cookie name/value pairs.  A special digital signature cookie would be used to sign them all so that on subsequent requests, the server could verify all the information stored in these cookies.

Step #4 might be problematic as the URLs could get quite large.  Who knows if a browser barfs on absurdly long URLs.  In this cast we could do a double form-post.  IDP could response from a successful login with an HTML Form whose target is Example.com.  This form would have all hidden fields within it containing security metadata.  One particulr form parameter would have a digital signature (I think SAML HTTP bindings work like this).

One vulnerability here is the cross-site scripting hack.  Most website already have this vulnerability I believe, so using existing techniques would be best.  I’m not sure how website solve this particular problem, but the HttpOnly flag could be used with each session cookie.  Javascript apps could have their javascript dynamically generated by the server and include the necessary code to manually apply and send the appropriate cookies.  Another thing that might mitigate things, is to include a timestamp with the cookies.  The application server would check for stale timestamps and with each request reset the digitally signed cookies with a new timestamp.

Non-Browser Clients Use Cookies Too

For non-browser clients, they could use a simpler RESTful protocol to obtain a signed URL or the set of signed form parameters.  There’s also no reason they couldn’t get a set of signed cookies instead of either of these approaches.

 

 

Is anybody doing HTTP message signing and encryption?

1 Comment

Over the past 6 months off and on I’ve been researching and prototyping various security related features for Resteasy.  One thing I’ve wondered is, is anybody really doing anything with HTTP message signing and encryption?  Email seems pretty well rounded in this area with specifications like DOSETA/DKIM and SMIME.  You could theoretically apply these specifications to HTTP, and I have, but I could find no examples of people doing so on the Web.  Maybe its just that my Google searching skillz are poor.

Another thing I’ve noticed is that the crypto libraries (bouncycastle and python’s M2Crypto) pretty much center around email as the protocol and you have to dive into the codebase a bit to figure out ways to transmit things over HTTP. Bouncycastle relies on javax.mail multipart implementation which is a bit limited and not very lenient on parsing (Didn’t like python’s SMIME output).

Anyways, I hope to do a Resteasy 2.3 beta soon with SMIME support.  With it I’ll have examples of Python clients posting to Resteasy services transmitting SMIME formated requests.  I’ll post a few blogs on the subject so you can see how to transmit SMIME between M2Crypto and Bouncycastle. (Python and Java).

In the meantime, does anybody have any experience in this area?

Decentralized Auth Ideas

7 Comments

Distributed workflow has to be the most complex use case to secure.  In it you could have multiple participants being coordinated both synchronously and asynchronously.  All forwarding and distributing information and data in between each other.  All needing to trust one another.  If you could define a relatively scalable and simple solution for workflow, you’d have something that would work in less complex scenarios.

The hub and spoke model that seems to be popular involves a central identity management provider (IDP) that participants ping to authenticate requests and to receive security information.  The biggest problem I foresee with this approach is that the IDP becomes a central point of failure.  The IDP needs to be available for applications to work.  It needs to be on the same network.  There’s a lot of extra distributed requests that need to be made.

All these problems bring me to thinking about the stateless principle of REST.  RESTful services can have state, but not session state.  The idea is that session state travels with the request.  Could we do something similar with security information?  Sure why not!  How could you trust the integrity of such information?  Digital Signatures.  I’m sure there are protocols out there that have thought of similar ideas, but its cool to think things out for yourself.  If your ideas match a particular existing protocol or specification you know you’re on the right track.  The idea have have works as follows.

Let’s pretend we have a User named Bill that wants to interact with a Travel Agent service that will buy a ticket for him on an airline, reserve an airport taxi, and reserve a hotel room.  So, Bill is interacting with the Travel Agent directly.  The Travel Agent is acting on behalf of Bill when it interacts with the airline, taxi, and hotel services.  The airline, tax, and hotel have to trust both the travel agent and Bill.

Step 1: Bill authenticates with an IDP saying he wants to interact with the Travel Agent.  The IDP returns metadata that specifies both Bill’s and the Travel Agent’s permissions for all the interactions that must take place.  It also returns the public keys for Bill and the Agent.  The IDP digitally signs all this information using its private key.

Step 2:  Bill sends a reservation request to the Travel Agent service.  Bill signs the request including the signed permissions and keys provided by the IDP.  Here’s what the request might look like:

POST /travel
Host: travelagent.com
Content-Type: application/reservation+xml
Authorization: doseta-auth user=bill;h=Visa:Permissions:Public-Keys:Host;verb=POST;path=/travel;bh=...;b=...
Visa: initiator=bill;h=Permissions:Public-Keys;d=idp.com;b=...
Permissions: bill="agent hotel airline taxi"; agent="reserve-hotel reserve-taxi reserve-flight"
Public-Keys: bill=23412341234;agent=3423412341234

<reservation>...</reservation>

Step 3: The Travel Agent authenticates and authorizes Bill’s request.  The Authorization header contains metadata that is signed by Bill.  The metadata signed by bill is the HTTP verb and path of the request (POST and /travel), and the hash of the XML posted by the request, as well as the Visa, Permissions, and Public-Key headers included within the request.  The Travel Agent verifies this signed metadata by finding and using Bill’s public key in the transmitted Public-Keys header.  If the signature passes, then the Travel Agent knows that Bill sent the request.  But….It does not know yet if Bill is a trusted identity.

Step 4: How does the Travel Agent know Bill is a valid person?  How does it know that Bill is allowed to make a reservation?  To answer these questions, the Travel Agent first looks at the transmitted Visa header.  What it boils down to is that the Travel Agent only trusts the IDP.  The Visa header was generated by the IDP and  is a digital signing of the Permissions and Public-Keys header.  The IDP  through the Visa header tells the Agent the permissions involved with the request and who will participate in the overall interaction.   The Agent only needs to know the IDP’s public key prior to the request being initiated.  So, the Agent verifies the digital signed Visa header using the stored public key of the IDP.  A successful verification also means that the Agent can trust that Bill initiated the request.  It can then look at the Permissions header to determine whether or not Bill is allowed to perform the action.

Step 5:  Next the Travel Agent needs to interact with the Airline, Hotel and Taxi services on behalf of Bill.  Here’s what a request to the Airline might look like.

POST /flights/tickets
Host: airline.com
Content-Type: application/ticket-purchase+xml
Authorization: doseta-auth user=agent;h=Visa:Permissions:Public-Keys:Host;verb=POST;path=/flights/tickets;bh=...;b=...
Visa: initiator=bill;h=Permissions:Public-Keys;d=idp.com;b=...
Permissions: bill="agent hotel airline taxi"; agent="reserve-hotel reserve-taxi reserve-flight"
Public-Keys: bill=23412341234;agent=3423412341234
<purchase>...</purchase>

You’ll notice that the Visa, Permissions, and Public-Keys headers are the same values as the original request made by Bill.  The Authorization header is different as the Travel Agent is making the request.  The airline services does authentication and authorization of the Agent’s request the same exact way the Agent did for Bill’s request.  Again, the key part of this is that only the IDP is trusted and only the IDP’s public key needs to be known ahead of time.

Vulnerabilities

Disclaimer, I’m new to security so dealing and thinking about attacks is new to me.  Generally a lot of attacks can be prevented by specifying a timestamp and expiration with each sign piece of data.  Services can refuse to honor old requests.  Nonces could also be included within signature metadata to avoid replays.

User’s Private Key is compromised

User’s authentication with the IDP doesn’t have to be key based.  It could be TOTP based where the user has to login through his browser providing a password along with a device-generated time-based key.  The IDP could then return a temporary private key the client uses to sign requests.

IDP’s Private Key is compromised

This is a scary one.  Maybe it could be prevented by requiring and acquiring Visa’s from multiple IDPs?  A service would verify signatures from two or more IDPs.  The probability of more than one IDP’s private key being compromised becomes less and less the more IDPs you have involved with the interadtion.

Summary

So here’s a summary of this brainstormed protocol:

  • The Public-Keys header’s purpose is two-fold.  First, its a list of public keys.  More importantly it is a list of principles that are involved with the interaction.
  • The Permissions header is a list of permissions of each principle involved for each service they will interact with.
  • The Visa header is a digital signature of the Public-Keys and Permissions header.  It also will probably have a timestamp and an expiration as well (all digitally signed of course).
  • The Authorization header exists to verify the integrity of the HTTP request of the entity sending the request.  It is a digital signature of the HTTP verb, path, host, message body, Visa, Permissions, and Public-Keys headers.
  • The IDP is the only trusted entity in the whole multi-tier distributed interaction.
  • Each service must have the IDP’s public key stored at deployment time prior to servicing any requests
  • There is no communication to the IDP by any service.  Even the initiating client’s first interaction with the IDP to obtain a Visa could be done ahead of time and re-used for multiple interactions.

This is just a rough outline, but there’s probably other things that could be added.  Like nonce’s for instance.  Its just a matter of implementing it and getting people to use it.  The real question is, is there an existing protocol already out there that does this sort of thing?

Follow

Get every new post delivered to your Inbox.

Join 691 other followers

%d bloggers like this: