March 12, 2014
Keycloak, oauth, openid connect, security, SSO
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
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.
January 24, 2013
java, JAX-RS, oauth, REST, RESTEasy
Resteasy 3.0-beta-2 has been released. Follow the links from our main jboss.org page to download and view the documentation. Here are the highlights:
- Added a new ResteasyClientBuilder class to make it easier to create HTTPS/SSL connections on the client side
- Extensive work on OAuth 2.0 support including tight AS7 integration.
You can find out more about our OAuth 2.0 stuff here, and the distribution comes with an extensive example. Here’s the overall features of it:
- Turn an existing servlet-form-auth-based web application into an OAuth 2.0 provider.
- Provide Distributed Single-Sign-On (SSO) from a central authentication server. Log in once, and you can securely access any browser-based app configured to work in the domain.
- Provide Distributed Logout. Following one link from any application can log you out of all your distributed applications configured to use SSO.
- Web apps can interact securely with any remote restful service by forwarding access tokens through the standard Authorization header.
- Access tokens are digitally signed by the oauth2 framework and can be used to access any service configured to work in the domain. The tokens contain both identity and role mapping information. Because they are digitally signed, there’s no need to overload the central authentication server with each request to verify identity and to determine permissions.
What’s next for Resteasy? Next release I’ll be focusing on getting it up to date with the latest JAX-RS 2.0 snapshot. I also have to get started on my O’Reilly book.
November 15, 2012
oauth, REST, security
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.