×

IDMWORKS Blog

oam, unsolicited login, and ssl


Problem:

So maybe my pain will help someone else. I recently encountered an issue when combining OAM, Unsolicited Login and SSL. I had configured everything properly in a test environment so that Unsolicited Login worked properly over HTTP. Testing verified everything worked properly. As soon as we switched to using our HTTPS-only endpoints everything broke.

This scenario should only occur if you are in an HTTPS-only environment for a reason to be described below.

It turned out that somehow, despite specifying our successurl as:

OAM translated that value as http://myserver.example.com/application.

As such we saw the following in the logs:

Workaround:

Obviously, this behavior is not desired. We found a workaround and then finally a fix. The workaround is simply configuring our successurl as the following:

On the first redirect, the 443 drops from the URL and our application functions as expected. The workaround actually introduces a slight delays since it has to do that redirect. The fix does not have that (very) slight delay.

Fix:

Now the fix is to simply add myserver.example.com:80 to the host identifier in your application domain.

Some references suggest adding it to IAM Suite’s Host Identifier, but we found it worked with our actual Application Domain Host Identifier which kept things all in one place.

Root Cause and Explanation:

The reason for this behavior has to do with how OAM parses the successurl.

OAM just verifies that http or https exists in the successurl. (If you do not prefix with http or https you will receive protocol errors. Something along the lines of invalid protocol:myserver.example.com)

For some reason, OAM doesn’t understand that https means port 443. It just assumes that both http and https refer to port 80.

OAM then goes on to parse the rest of the url as normal. Once everything is parsed, it checks the host identifier list to make sure that there is an applicable Authentication Policy to evaluate.

Since our application was in an HTTPS-only environment, we had not defined a Host Identifier for port 80 only 443. Adding our server url with port 80 into the host identifier list cleared things up and we were able to verify our environment.

Just to note, this does not mean that port 80 is open or even accessible (it is not) but now OAM can successfully match the url against the policy and then the browser will handle the actual redirect url using the full https://myserver.example.com/application as the URL.

Maybe this post will alleviate headaches for someone else along the way.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *