Red Hat

PicketLink 2.7.1.Final is out!

We’re very pleased to announce PicketLink v2.7.1.Final release.

Thanks the community for all feedback since the last release. This release includes a number of bug fixes over the last release.

More details about the issues resolved by this version can be found on the Release Notes.

PicketLink and Keycloak projects are merging!

Together with new PicketLink 2.7.0.Final release, we would like to announce that PicketLink and Keycloak projects will be merging their efforts. Code base of both will get unified and new features will be developed in a single place.

As part of this merge all key features of PicketLink will get included into Keycloak. Combining strengths of both projects and providing their communities a single polished and unified security solution. Joining both efforts should enable faster progress on new features which will be beneficial for all users and developers leveraging those solutions.

PicketLink project was originally started being a central hub for all security related efforts for Red Hat Middleware. It is a security framework providing a rich set of capabilities for Java EE applications including Authentication, Authorization or Permissions APIs and flexible IDM solution. One of other key features adopted and used in many organizations world wide is Federation component providing SAML Identity and Service Provider capabilities. On top of that it contains a toolbox of different useful APIs and helper classes in identity and security areas.

Keycloak origins

Keycloak initially originated as a merge of two initiatives. First one was SkeletonKey module from RestEasy project aiming to provide easy security for REST APIs in Java EE world. Second part was a prototype to provide easily consumable Social Login capabilities in a form of Identity Broker. Both merged together with aim to expose out of the box security capabilities for application developers that they could seamlessly integrate.

Reasons for merging both projects

While both project initially covered slightly different areas and angles they naturally started overlapping over time. Keycloak from being Identity Broker grew into being fully fledged Identity Provider. Initially it was only exposing basic token based security for REST APIs built on top of OAuth2 spec. Currently it aims full OpenID Connect interoperability, providing base SAML IdP capabilities and working on developing integration points via Kerberos or Identity Provider Brokering set of features. With all of this work happening Keycloak naturally stepped into area which was initially covered by PicketLink with it’s framework capabilities.

Major difference between PicketLink and Keycloak has always been framework vs out of the box nature of both solutions. PicketLink was always focusing on providing easily used set of base features with flexibility to extend them your way to build on top. This is still the key strength that many users love. It acts a security toolbox from which you can pick from according to your needs. Original idea behind Keycloak was to provide out of the box solution which could be embedded or integrated into your application. Externalizing most of common security capabilities that developers need to repeatedly provide for their applications - like login screens, OTP or social login. All of those features accompanied with extensive and well designed UI console, resulted in skyrocketing adoption in the community

Developers engaged in both projects started hearing repeating questions from community users around overlap, differences and their future. After long debates we decided it is high time to merge them!

We will start merging key parts of PicketLink codebase into Keycloak and proceed further under this project name.

What you can expect happening during next few months?

  • Specific parts of PicketLink codebase being forked and merged into Keycloak. We are starting with PicketLink Federation / SAML.

  • Inclusion or implementation of particular features will get discussed in public on the Keycloak project mailing list. We are looking forward for your participation there as we would like to hear your feedback on changes that we are doing.

  • Web sites for both projects will get slightly changed to reflect new situation.

  • Many new cool features coming shortly!

Short answer is - nothing dramatic really… No one is switching the lights off! All project sources, materials and communication channels will still remain available and open for the community. Developers associated with Red Hat will be focusing much more on new features development in Keycloak project. However if there are contributions coming in from the community we’ll still assist you as much as we can. Although expect repeating encouragement from our side to try Keycloak out everytime you ask for a new PicketLink feature ;)

We hope it will answer most of your questions or concerns.

Bill Burke and Stian Thorgersen - Keycloak Project Leaders

Bolesław Dawidowicz - Security Platform Architect at Red Hat.

PicketLink 2.7.0.Final is out!

We’re very pleased to announce PicketLink v2.7.0.Final release, finally.

Thanks the community for all feedback since the last release. This release includes a number of improvements and bug fixes over the last release.

  • The Http Security API now supports CORS. Now you can enable and configure CORS for each of your protected paths or path groups.

  • For those using JSF, a new example was added to our quickstart repository that demonstrates how to perform FORM authentication using JSF and the Http Security API. You can find the quickstart here.

  • Better integration with PrettyFaces Rewrite.

  • Better support when using PicketLink JEE Security in HA environments.

  • Added support for Managed Attributes. This is a major improvement on how you create your identity model, specially when using JPA. In conjunction with the Default Schema, you can write your own types very easily without create their corresponding JPA entities. Managed attributes allows you to store properties as ad-hoc attributes and still use them in a type-safe manner.

  • Permission API is now supporting cross-partition references for identity types. That means you can use, for example, a LDAP identity store for your users and still be able to manage permissions for them using a JPA identity store.

  • LDAP authentication was improved in order to authenticate users despite their location in the LDAP tree. This is specially useful if you are using PicketLink and LDAP in read-only mode.

  • Improvements to Backchannel Logout, specially when using SSL/TLS.

  • A number of important bug fixes and improvements.

More details about the issues resolved by this version can be found on the Release Notes.

Latest News

back to top