Unsolicited login with OAM 11gR2

In a previous post Chris Johnson has discussed unsolicited login with OAM 11g.

In OAM 11gR2 this functionality is supported out of the box and with little effort you can implement Unsolicited Login.

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

If you're interested to authenticate using unsolicited POST, please read on…

The complete procedure is explained in the official documentation here, but the docs are not clear on some aspects of the configuration.

To begin with, the documentation states that you have to manually edit the oam-config.xml file, but it does not say where to find it or which one to edit.

In my lab installation, I found six different oam-config.xml scattered across several folders.

After some trial and error I found out that the correct one to edit is OAM_DOMAIN/config/fmwconfig/oam-config.xml. 

Where OAM_DOMAIN is the WLS domain folder for the OAM domain.

Don’t forget to bounce Admin and Managed Servers after editting the oam-config.xml.

Note that in a distributed environment you want to make changes to the file on the admin server and it will then get pushed out to the managed servers after restarts.

Now all you have to do is post the login info to the endpoint https://oam_host:oam_port/oam/server/authentication.

The required information you need to post to the endpoint is:

• username
• password
• successurl

     If the authentication succeeds, you will be redirected to the successurl you passed to the endpoint.

     In case the authentication fails, you will be redirected to the default OAM error page:

      Now, that isn’t very nice, right?

        If you want to get redirected to a custom error page, for instance, to the same login page with the error message displayed in it so you can try to login again, you just need to edit the Authentication Policy for the /oamDirectAuthentication resource (we will talk about this resource further on).

      To do so, go to Application Domains, IAM Suite, Resources and search for /oamDirectAuthentication.

        Open it and edit its Authentication Policy to include the Failure URL to the page you want to be redirected in case of authentication errors.

        If you don’t want to mess with the default Authentication Policy, which is used by other Resources, you can create another Authentication Policy for this resource and make the required changes.

        To display the errors messages, check out the docs about creating Custom Error Pages here 

        To test the whole thing, you can use a simple JSP to post the info to OAM:

        And for the JSP of the success URL I print all the request parameters, headers and session attributes:

         From this point on, you’re already authenticated to OAM and you can access any resources you’re authorized to.

        The documentation also describes how you can combine different HTTP operations (POST, GET, DELETE, etc) with different Authentication Schemes (FORM, CERT, etc).

        If you have specific requirements for the unsolicited login, you can create/edit the /oamDirectAuthentication Resource of IAM Suite Domain. This resource controls all the specifics of unsolicited authentication, for example, allowing only for HTTP POST and FORM based authentication.

        The resource /oamDirectAuthentication is a virtual resource that is defined in the system that represents the physical endpoint for unsolicited login. 

        So, when it comes to policy configuration you will always deal with /oamDirectAuthentication, however when it comes to the physical endpoint (the actual servlet URL for posting information) you will use /oam/server/authentication.