OpenAM RESTful APIs and Cross-Domain Single Sign-On

While reading the OpenAM Mailing list this morning, a community member has the following requirement:

1. A few PHP applications to be SSO-ed
2. Cannot redirect to OpenAM Login Page for authentication, which implies

• Cannot use Policy Agent
• Can only use OpenAM RESTful APIs

I thought that simple requirement. But he followed by asking: "Is there any way to do CDSSO with REST API without use of Policy Agent ?"

Huh?

I blogged something like this before - OpenAM RESTful Services.

I think he mis-understood the concept slightly - CDSSO (cookie-based) vs RESTful APIs.

… if one is to use RESTful Web Services, please do not work with cookie. Make it a pure RESTful experience!

.

OpenAM - Issue with Unvalidated Redirects defined in OWASP A10

We received a ticket from one of our customers reporting an issue. They thought they found a vulnerability with OpenAM.

I found one vulnerability of SSO. It is about Unvalidated Redirects which is defined in OWASP A10. 

For example, when I tried to input the url in IE, I could successfully be redirected to my project URL. https://am.abc.sg/sso/UI/Login?goto=https://192.168.1.2:430/abc/Index

It should validate the returned url and reject my request.

My reply below:

The observation is a valid one. It is the default product behavior.  

You can, however, enhance security by setting allowed Goto URL domains by going to:
/ (Top Level Realm) -> Authentication -> All Core Settings ... -> Security -> Valid goto URL domains  

By default OpenAM will redirect the user to the URL specified in the goto parameter supplied to the authentication interface. To enhance security a list of valid DNS domains can be specified. OpenAM will only redirect a user if the domain of the goto URL is present in this list.

At least there is a way to tighten security if customer chooses to.


.

OpenAM Security Advisory - NSS and NSPR security

ForgeRock has just released a security advisory for OpenAM Web Policy Agent. This affects versions 3.3.1, 3.3.0 and 3.0.x. It's actually an issue with the NSS and NSPR libraries that the Web Policy Agent uses during runtime.

More detail here.

As usual, paid customers have the convenience of downloading the latest Web Policy Agent 3.3.2 from ForgeRock BackStage.

How about Non-paying customers?

If community members are using older versions of the Web Policy agents we strongly recommend updating to the new release at the earliest opportunity.

Watch out for new Web Policy Agent 3.4.0 or 4.0.0 if that's how I interpret correctly.


But I think for this issue, update the NSS/NSPR libraries will do. Isn't it? :)


.

 

OpenIG 3.0 Released

OpenIG has been quiet for a long while. The latest 3.0 version has just been released!

As organizations roll out new applications and APIs they need extremely agile ways of identity-enabling these services so they can expose them to the customer. Whether it be to offer more value to end-users or to monetize a new service, the ability to tie identity to these offerings is critical. With OpenIG, organizations can quickly identity-enable applications and APIs for roll-out and monetization.  

Key release highlights include: 

• Extends your authentication, authorization, and risk policies to mobile, cloud, and enterprise applications – without the need to change backend applications. 

• Integrates smoothly with existing, standards-based Identity Providers (e.g. OpenAM, SAML 2.0 IdP, Google OpenID Connect). 

• Protects machine-to-machine communications and API access, leading to immediate revenue opportunities.

See http://forgerock.com/products/open-identity-stack/openig/.


I thought no one is using OpenIG. The fact that ForgeRock invested time and resources into building Release 3.0 (Release Notes) proves that I'm wrong. :)

.