Last week’s entry summarized new OAuth 2.0 and OpenID Connect related features that you can try in the nightly builds of OpenAM. But those aren’t the only important changes for the next major release. Among the many others are changes to policy management, including a slick new UI for creating and editing policies.
Rest assured that your existing agents and existing policies still work fine after you upgrade your OpenAM servers. Policy evaluation works as it did before. What’s been done is to take full advantage of the newer policy engine implementation that is already in use today behind the scenes, but not made visible in OpenAM 11.
The new policy editor (re)introduces the notion of application. An application serves as a template for policies, and helps you to group policies. When you open the policy editor in OpenAM console, the first thing you see is the list of applications for the realm where you are managing policies. The default application in the top-level realm, geared for web and Java EE policy agents, is named (with a bit of nostalgia for the old folks)
You can then drill down to create or edit a policy that belongs to this application.
Notice the policy for the OAuth 2.0 authorization server & OpenID Provider. It is when you start creating or editing the policies that you see the strongest features of the new UI.
As you see in this excerpt (conditions and response attributes are not shown), the policy editor works like a wizard, guiding you through the steps to build your policy. You can build up subject and environment conditions using the logical operations. The image shows a subject condition for all authenticated users but not the demo user.
One thing to keep in mind if when creating your own applications, especially in sub-realms: OpenAM can now direct policy agents straight to an application, so you don’t always need referrals (unless for example you want to have a policy agent protecting multiple applications). This is done with a couple of new properties in the policy agent profile. Here’s a snapshot of the Policy Client Service section of a web policy agent profile screen showing the new properties.
These properties are not actually used by the policy agent, but instead by OpenAM, when it directs policy decision requests to the right realm and application.
Underlying the new UI is a full REST API for policy management and policy evaluation. The REST API opens up additional application types, letting you describe applications where the verbs are not necessarily those of HTTP, and write custom policy enforcement points for such applications.
There are still a few changes forthcoming in the UI, and the documentation is catching up with the code, but this is something you can start playing with already in the latest builds.
This blog post was first published @ marginnotes2.wordpress.com, included here with permission.