Thursday, March 28, 2013

ForgeRock Product Release Levels

I must say ForgeRock is getting more and more organized in terms of their product releases.


ForgeRock defines Major, Minor, and Maintenance product release levels. The release level is reflected in the version number. The release level tells you what sort of compatibility changes to expect.



Read more here .... There's another link which is also important to note: Stability of Product Interfaces .


Good job!


.

Monday, March 25, 2013

OpenAM Policy Agent for Apache HTTPD server

My customer has this weird problem with OpenAM Policy Agent for Apache HTTPD server which I can't explain yet.


We know if we want immediate policy/configuration update from OpenAM, we can restart the Apache HTTPD server and the new configuration will be fetched from OpenAM server.

Well, he did restarted the Apache HTTPD server as what I had instructed him to do. But whenever he did it himself, it'll not work. There's no change to the new configuration. However, if I helped him to perform the restart, it'll work 100% of the time!

Very strange!

I found out the difference later.

HE: $./apachectl restart

ME: $./apachectl stop; ./apachectl start


Why? I seriously do not know why. My main concentration last week was on another task. So I didn't spend the time debugging why.

Seriously very strange!

.


Wednesday, March 13, 2013

Invalid Credential when Add to Existing Deployment - Part III

In my previous post, I talked about encountering the same Failed to create new Authentication Context: null error even though I have followed the instruction to change to "adminconsoleservice" login.





org.apache.jasper.JasperException: An exception occurred processing JSP page /getServerInfo.jsp at line 76 

73: 
74: AuthContext lc = new AuthContext("/"); 
75: //AZLABS lc.login(); 
76: lc.login(AuthContext.IndexType.SERVICE, "adminconsoleservice"); 
77: while (lc.hasMoreRequirements()) { 
78: Callback[] callbacks = lc.getRequirements(); 
79: ArrayList missing = new ArrayList(); 


So, I spent some time yesterday to investigate why.


First, I started by manually testing via the UI using .../openam/UI/Login?service=adminconsoleservice.

Bingo!

It's very obvious why the Authentication Context is null. The administrative account "amadmin" is used during configuration, thus by showing a Active Directory Authentication module, the "amadmin" user is never ever going to be able to login.




So, this has to be fixed. 

With the same URL .../openam/UI/Login?service=adminconsoleservice, the following UI has to be shown in order for the amended code to work.




However, I do not know what has gone wrong with the initial configuration at first. It took me quite a while to discover. It has got to do with how the Organization and Administrator Authentication configurations are arranged.


In fact, I have not made any change to it. It comes by default.




What I have changed, however, is the ldapService in Authentication Chaining.

I have toggled the default DataStore instance to AZAD instance. This is to allow all users to authenticate via Microsoft Active Directory by default. For administrator, he/she has to manually append the module=DataStore to the URL - .../openam/UI/Login?module=DataStore.






I found out that this is the root cause!

What's the workaround?

Step 1: Create a new Authentication service - azService.


Step 2: Choose AZAD as the default instance.



Step 3: Toggle back to DataStore instance for Authentication service - ldapService.



Step 4: Now, this is the important step. Change Organization Authentication Configuration from ldapService to azService.


Test accessing the URL .../openam/UI/Login?service=adminconsoleservice again. Now the UI is what I am expecting!



And of course, the OpenAM Configurator wizard is no longer complaining now. Happy!


.




Monday, March 11, 2013

Invalid Credential when Add to Existing Deployment - Part II

With the release of OpenAM 10.1 Xpress, I was keen to find out whether or not a previous issue I encountered while configuring a 2nd instance of OpenAM via the wizard has been solved.



Too bad.. not resolved yet. In fact, as pointed out, there is a bugster raised for this issue. (See here for more info)

Sad thing is when I go to the Tomcat webapp for OpenAM 10.1-Xpress, the source code in getServerInfo.jsp has not been modified at all.

The catalina.out showed the following trace stack:

org.apache.jasper.JasperException: An exception occurred processing JSP page /getServerInfo.jsp at line 75 72: } 

73: 
74: AuthContext lc = new AuthContext("/"); 
75: lc.login(); 
76: while (lc.hasMoreRequirements()) { 
77: Callback[] callbacks = lc.getRequirements(); 
78: ArrayList missing = new ArrayList(); 

Stacktrace: at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:568) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:455) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1780) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.servlet.ServletException: com.sun.identity.authentication.spi.AuthLoginException: Failed to create new Authentication Context: null


I took a look at the Fisheye and discovered the fix. So I went ahead to change the source code in getServerInfo.jsp.



No luck also.

org.apache.jasper.JasperException: An exception occurred processing JSP page /getServerInfo.jsp at line 76 

73: 
74: AuthContext lc = new AuthContext("/"); 
75: //AZLABS lc.login(); 
76: lc.login(AuthContext.IndexType.SERVICE, "adminconsoleservice"); 
77: while (lc.hasMoreRequirements()) { 
78: Callback[] callbacks = lc.getRequirements(); 
79: ArrayList missing = new ArrayList(); 

 Stacktrace: at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:568) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:455) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1780) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.servlet.ServletException: com.sun.identity.authentication.spi.AuthLoginException: Failed to create new Authentication Context: null


Hopefully I have some time to play with the source code tomorrow.


.

Saturday, March 9, 2013

Cross Domain Single Sign On - What's it?

The concept of why a cookie created specifically for a particular domain cannot be accessed by another domain has been explained repeatedly year over year.

A lot of articles tried to explain, but in words, which can get a little complicating. (ok, maybe to me :>)

The following diagram explains it all. (yes, OpenSSO articles is still the to-go place for reading-up concepts)


Clear and precise. Why talk so much when a simple diagram can do the job? (maybe technical writers just like to write, but doesn't like to draw)


To introduce CDSSO, each SSO product implement its proprietary mechanism to support single sign-on across multiple domains. 


OpenAM / OpenSSO introduced Cross-Domain Controller Servlet (CDCServlet) to handle CDSSO.



SiteMinder introduced Cookie Provider to handle the same scenario.




.

Friday, March 8, 2013

OpenAM HMAC-based One Time Password

There are many Authentication modules available out-of-the-box from ForgeRock OpenAM. One of them is HOTP - HMAC-based One Time Password.

Fairly easy to configure and integrate with the default LDAP module. So, the user will be first prompted with a user name and password fields to key in. Once successful, he/she will be redirect to the HOTP page to key in the OTP.


The previous implementation of HOTP in OpenAM was a little cumbersome such that user has to manually click on "Send OTP" button in order to fire the sending of the OTP to the user's email and/or SMS.


This feature has been enhanced in the latest release of OpenAM 10.1. (I'm not too sure of 10.0.1, but I'm pretty sure 9.5.x doesn't have this feature). The latest enhancement is to "Auto Send OTP Code".

Simple enhancement, yet it makes the user experience so much better!

.

Wednesday, March 6, 2013

Federation: Redirect POST vs POST Artifact

I attended an Identity course last week and Federation was covered (of course).



We covered Redirect-POST and POST-Artifact and made some comparison.

Well, whenever I need diagrams on Federation, I always go to PingIdentity. Their document is tip-top - my #1! So, here's the link ...


I should say Redirect-POST is the most commonly deployed.


Most activities revolves around redirection via the user's browser. Easily achievable.


When it comes to POST-Artifact, the problem lies in the highlighted red box.


Usually, when different organizations choose Federation for integration, they would most likely not like to expose their backend identity infrastructure as much as possible. However, POST-Artifact requires the Federation Servers in the SP side and the IdP side to communicate to each other.

Adoption rate will be definitely low, as one can easily predicate. 


.





Tuesday, March 5, 2013

Fix for the famous Configuration Options page

I just saw a new fix for OpenAM (OPENAM-2230 - Users should not be redirected to config/options.htm if OpenAM has already been configured but the config store is unavailable).

This fix is to resolve the famous Configuration Options page which I have blogged about here and here some time back.



And the solution is exactly what I have suggested way back in 2011!



Stay tuned, the fix will be incorporated in the next release of OpenAM - 10.2!

Cool!

.


Monday, March 4, 2013

Cross Domain Single Sign-On

In an environment where there are multiple domains and single sign-on across the domains is required, CDSSO (Cross Domain SSO) shall be utilized. This is a good article to kick-start.





When using CA SiteMinder, the same can be achieved via Cookie Provider. The concept is pretty similar to that in OpenAM.



OpenAM uses iPlanetDirectoryPro as its cookie name; SiteMinder uses SMSession.

.