Sunday, October 13, 2013

Does OAM DCC Support Programmatic Authentication? - Maybe not yet!

Credential Collection is the process of collecting the end user's credentials through a login page. When OAM Webgate intercepts a requests and detects the user is not authenticated yet, it would redirect the user to the login page. In OAM, when the login page is hosted on the OAM server, it's called Embedded Credential Collector (ECC).

Another form - Detached Credential Collector (DCC) - is introduced in OAM 11gR2. As the name explains, DCC can be decoupled from the OAM server, which provides the flexibility of deploying the login page in either trusted internal network or DMZ. It uses a specific WebGate to collect he user credential and communicate to the OAM using secure Oracle Access Protocol (OAP). It offers a solution that isolates the OAM serve from any unauthenticated network connection, such as public access.

It is my interest to discuss on whether DCC supports programmatic authentication. Usually the login page for OAM authentication would be form based JSP page with the following snippet:

  <form id="loginData" name="loginData" method="POST" action="/oam/server/auth_cred_submit">  
      <table cellspacing="2" cellpadding="3" border="1">  
       <tr>  
        <th>Username:</th>  
        <td>  
         <input id="userid" type="text" name="userid" autocomplete="off"/>  
        </td>  
       </tr>  
       <tr>  
        <th>Password:</th>  
        <td>  
         <input id="password" type="password" name="password" autocomplete="off"/>  
        </td>  
       </tr>  
      </table>  
      <p>  
       <input type="submit" name="submit" value="Login"/>  
      </p>  
      <!--<input type="hidden" name="request_id" value="${param.request_id}" id="reqid1"/>-->  
      <!--<input type="hidden" name="OAM_REQ" value="${param.OAM_REQ}" id="oamreq1"/>-->  
     </form>   
Note the important thing in the snippet is the HTML form component with "POST" method and "/oam/server/auth_cred_submit" action. The user id input id and password input id have to match the settings on OAM server. You might notice the "request_id" and "OAM_REQ" parameter is commented out and they are not required by the DCC (but they are required by ECC authentication though).

Oracle documentation did talk about the programmatic authentication here - "Programmatic authentication using HTTP client APIs is supported for both OSSO 10g and 11g OAM Server". This is true for ECC authentication, but not for DCC. I will explain why.

In case of DCC, the user sends a request to access an OAM protected resource. The webgate will detect that and redirect to the login page with a DCCCtxCookie. The cookie looks like this:

Cookie: DCCCtxCookie_host:port=encdata%3DK1%2Fz6ZK1yVCemO56M9Zs9DfIY%2Fui4r%2BQaoWbA8rxRf%2FgJ68egTxUyOC4G%2F2Ufj8gQwEgL36wlEEevfNm5ETfaw4PwDVMVj3MRkHfvZSmBCPsFC6T4z9tS98ehpAxZjhx8cJN2ELvMycCrgqQFNEd23WbRzRq4YCLt9edz%2Ba1gekDhjIMKLYMZrNrlmv1krsIV4PYnQWydY5pmfpYfh%2BYPyumYWMt%2Bm6syK9nmruSM%2BOSKu39PxBV6TL1S3wWpWgXLFmpS6Jq5Xt6cBGWaMbCaVnfcQQdN%2BSIfFLz0kA8u8Fxq9Z4dB9MGQoWzE165KDHRKsVPgMN81M%2F84ju3Cximw%3D%3D;

This cookie is sitting on the path "/oam/server/auth_cred_submit" but not on the domain "/" like JSESSIONID. This makes the cookies not accessible from Http Client API. Without this DCCCtxCookie, submitting the login page with action "/oam/server/auth_cred_submit" would result in 404 - page not found.

Different from ECC, the cookies generated for ECC authentication are sitting on the domain path so it can be accessed from the Http Client API.

Due to this cookie path challenge, I am making a conclusion that the DCC is not supporting programmatic authentication yet. I hope others can correct me and show me an alternative or workaround for this matter.

Assuming DCCCtxCookie is present, OAM will authenticate the credentials on submitting the login form. If the credential passed the authentication, a cookie "OAMAuthnCookie" will be set and available on the response header.

Set-Cookie: OAMAuthnCookie_host:port=qLhahoJixOlOMO%2F9mCzrd80IPFoaswuOA%2F59re%2Bo%2FREiXuKMFfzicypCssemSZLLBwaGIZawYc6TnymVPUppQQKolyt015hJuas5xYIbK3rCT4SgI%2BMYdlsPpeyy1IFvpFEHWVbLJ%2Fkd94SYoiBwUWlNo7dEa7jVltmz8k8h2sJ4id%2FriGn2JCtxgUfPNGsF8FrIvO3xIkXCqo7c4LMPlZJrgxz5vW1Dt9FARC1eQ%2BzhNK4p9XYpogcuKEfGSwSEyzrQdiVPU82zx108uVKhNvlUvBPwwqhY38Dkpnecaouv6Gzo5XqEnac%2Bz8GB84UmVen6UXca8knu9lNzC2iRLi0356JSR27%2Fft4ESr%2Fpnlk%3D; 

Note to Jmeter test with the DCC cookie

The following info is provided by Flavia from the comments below: 

It's true that Jmeter cannot see the DCCCtxCookie_host:port by default, but if you set
CookieManager.check.cookies=false
In jmeetr.properties or user.properties, Jmeter can see the cookie. You need to restart Jmeter.

Another import thing that I found is set the "Follow Redirects" in the HTTP Request. I did for all my pages (specially "/oam/server/auth_cred_submit")

5 comments:

Anonymous said...

Hi, did you ever solve this? I'm having the same problem when trying to use JMeter....

Regards,
Bernie

Anonymous said...

Were you able to use jmeter with DCC?

Thanks
Sidd

Unknown said...

Hi,

Found this post when I was having the same issue. Now that I found the fix decided to post to make life easy for someone else. :)

I true that Jmeter cannot see the DCCCtxCookie_host:port by default, but if you set
CookieManager.check.cookies=false
In jmeetr.properties or user.properties Jmeter can see the cookie. You need to restart Jmeter.

Another import thing that I found is set the "Follow Redirects" in the HTTP Request. I did for all my pages (specially "/oam/server/auth_cred_submit")

Cheers,

Flavia

JayJay Zheng said...

Thanks Falvia for the info you provided. I will update the post with the info you shared.

PriKe said...

Thanks for the post, How to redirect to login page URL after authentication fails in DCC flow, Currently it stays on the /oam/server/auth_cred_submit.

and What is the use of "Follow Redirects".