Recently, there was a customer requirment to enable a WebCenter custom portal application to have multiple login-type pages and have the authentication be handle through Oracle Access Manager (OAM) As my security colleagues would tell me, this is fully supported through OAM.  Basically, all that would have to be done is to define in OAM individual resources (directories, URLS , .etc) that needed to be secured. Once that was done, OAM would handle the rest and the user would typically then be prompted by a login page, which was provided by OAM.  I am not going to discuss talking about OAM security in this blog.  In addition, my colleague Chris Johnson (ATEAM security) has already blogged his side of the story here:  http://fusionsecurity.blogspot.com/2012/06/protecting-webcenter-app-with-oam-11g.html .  What I am going to cover is what was done on the WebCenter/ADF side of things.

In the test application, basically the structure of pages defined in the pages.xml are as follows:

 In this screenshot, notice that "Delegated Security" has been selected, and of the absence for the anonymous-role for the "secured" page (A - B is the same) 

This essentially in the WebCenter world means that each of these pages are protected, and only accessible by those define by the applications "role".  For more information on how WebCenter handles security, which by the way extends from ADF security, please refer to the documentation.  The (default) navigation model was configured.  You can see that with this set up, a user will be able to view the "links", where the links define navigation to the respective page:

Note from this dialog, you could also set some security on each link via the "visible" property.  However, the recommended best practice is to set the permissions through the page hierarchy (pages.xml).  Now based on this set up, the expected behavior is that I could only see the link for secured A page only if I was already authenticated (logged in).  But, this is not the use case of the requirement, since any user (anonymous) should be able to view (and click on the link).  So how is this accomplished?  There is now a patch that enables this.  In addition, the portal application's web.xml will need an additional context parameter:

<context-param>
    <param-name>oracle.webcenter.navigationframework.SECURITY_LEVEL</param-name>
    <param-value>public</param-value>
 </context-param> 

As Chris mentions in his part of the blog, the code that is responsible for displaying the "links" is based upon the retrieval of the navigation model "node" prettyURL.  The prettyURL is a generated URL that also includes the adf.ctrl-state token, which is very important to the ADF framework runtime.  URLs that are void of this token, get new tokens from the ADF runtime.  This can lead to potential memory issues.

 <af:forEach var="node" varStatus="vs"
   items="#{navigationContext.defaultNavigationModel.listModel['startNode=/,includeStartNode=false']}">
                <af:spacer width="10" height="10" id="s1"/>
                <af:panelGroupLayout id="pgl2" layout="vertical"
                                     inlineStyle="border:blue solid 1px">
                  <af:goLink id="pt_gl1" text="#{node.title}"
                             destination="#{node.goLinkPrettyUrl}"
                             targetFrame="#{node.attributes['Target']}"
                             inlineStyle="font-size:large;#{node.selected ? 'font-weight:bold;' : ''}"/>
                  <af:spacer width="10" height="10" id="s2"/>
                  <af:outputText value="#{node.goLinkPrettyUrl}" id="ot2"
                                 inlineStyle="font-size:medium; font-weight:bold;"/>
                </af:panelGroupLayout>
              </af:forEach> 

So now that the links are visible to all, clicking on a secure link will be intercepted by OAM.  Since the OAM can also configure in the Authentication Scheme, the challenging URL (the login page(s)) can also come from anywhere.  In this case the each login page have been defined in the custom portal application.  This was another requirement as well, since this login page also needed to have ADF based content.  This would not be possible if the login page came from OAM.  The following is the example login page:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>
  <f:view>
    <af:document title="Settings" id="d1">
      <af:panelGroupLayout id="pgl1" layout="vertical"/>
      <af:outputText value="LOGIN FORM FOR A" id="ot1"/>
      <form id="loginform" name="loginform" method="POST"
            action="XXXXXXXX:14100/oam/server/auth_cred_submit">
        <table>
          <tr>
            <td align="right">username:</td>
            <td align="left">
              <input name="username" type="text"/>
            </td>
          </tr>
          
          <tr>
            <td align="right">password:</td>
            <td align="left">
              <input name="password" type="password"/>
            </td>
          </tr>
          
          <tr>
            <td colspan="2" align="center">
              <input value=" login " type="submit"/>
            </td>
          </tr>
        </table>
        <input name="request_id" type="hidden" value="${param['request_id']}"
               id="itsss"/>
      </form>
    </af:document>
  </f:view>
</jsp:root>

As you can see the code is pretty straight forward.  The most important section is in the form tag, where the submit is a POST to the OAM server.  This example page is mostly HTML, however, it is valid to have adf tags mixed in as well.  As a side note, this solution is really to tailored for a specific requirement.  Normally, there would be only one login page (or dialog/popup), and the OAM challenge resource would be /adfAuthentication.  This maps to the adfAuthentication servlet.  Please see the documentation for more about ADF security here.