views:

242

answers:

1

We've got an ASP.NET Application that the client would like to protect Via Oracle SSO and also allow anonymous access to the application.

None of the standard Oracle SSO plugins have an anonymous access option, so we wrote a custom java SSO plugin to check for Portal/SSO session cookies and do the base Oracle SSOServerAuth, and otherwise if they don't have an SSO cookie (anonymous access) - return the Oracle PUBLIC user.

Has anyone got a scenario like this to actually work properly? Is there a better way to do this?

We're using the Oracle SSO IIS plugin, and it works in some cases - but we're seeing some odd behavior in Portal that occurs after authenticating a user as the oracle PUBLIC user:

The login forms don't work with the custom and default plugin at the same security level. And with the custom plugin at a lower security level than the default plugin, the PUBLIC authentication is somehow persisted for the partner application even if the user logs into Portal with another account.

Here is our custom plugin:

public class MixedAuthenticator
       extends SSOServerAuth
       implements IPASAuthInterface
{

  public MixedAuthenticator()
  {
  }

  public IPASUserInfo authenticate(HttpServletRequest request)
         throws IPASAuthException, IPASInsufficientCredException
  {

       boolean foundPortalUser = false;

        Cookie[] cookies = request.getCookies();

           if(cookies != null)
           {
         for(int i=0; i<cookies.length; i++)
         {
          Cookie cookie = cookies[i];

          if(cookie.getName().equalsIgnoreCase("portal"))
          {
         foundPortalUser = true;
             }
         }
           }

     if(foundPortalUser)
     {
      return super.authenticate(request);
     }
     else
     {
          IPASUserInfo anonUser = new IPASUserInfo("PUBLIC");
          return anonUser;
     }
  public URL getUserCredentialPage(HttpServletRequest request, String message)
  {
    return super.getUserCredentialPage(request, message);
  }
  }
A: 

Turns out the answer to this was to delete the IAS_IDXXXXXXXX cookie created by the IIS SSO plugin before you try to allow the user to login as a non PUBLIC user.

jspru