This is the same process, but with a bit more detail of problems encountered along the way, and with the OpenID provider and OpenID client in separate domains.

While the OpenID Connect Provider is from CA SSO, the OpenID Client here is notan SSO setup (that will have to be a latter article). Here the OpenID Client is Apache httpd with mod_auth_openidc module.

It redirects to the IDC Connect Provider side, ask for credentials, where we login to www.example.com domain.

After successull login we are then redirected back to the client http://www.demo.com side, where our Apache24 OIDC protected resource is now accessible. The mod_auth_idc module in Apache then makes a backchannel call to our OpenIDC Connect Provider to get the attributes; sets the OIDC_ headers and then runs our little cgi dump script to display all the headers us.

Fiddler trace of the above transaction.

3) Policy to Protect the login realm

When the users comes over to the Access Gateway machine servicing the http://www.example.com/affwebservices/ URL we need them to logon to the Siteminder SSO environment before we can return the OpenIDC attributes. The Ag will already have an enabled webagent, and agent name, so we setup a normal, fairly simple, SSO protection scheme via a SSO domain, protected resource, rule and policy.

We are using the "Basic" auth scheme - but it could be any other auth scheme.

It contains one rule: AllowGetPost :

The realm is also marked as "Persistent Session" which it needs so that after login to the realm the policy server creates entries in the session store for the user session. The session store is used to store runtime attributes of the logged in user:

Note: It is important that the URL https://www.example.com/affwebservices/CASSO/oidc/authorize? is NOT protected, in the above this is because we only have the one very specific URI protected. But that may not be the case in your setup, as often everything under /affwebservices/ (except /affwebservices/public) is be protected. If so you will need explict rule to make /affwebservices/CASSO/oidc unprotected.

Then once accepted give us an 400 error page (which I have not included).

The policy setup is now complete.

4) Setup OIDC Connect Provider

Under the Federation menu item, we now have OpenID Connect with sub menu "Authentication Providers". We want to setup a Provider for our www.example.com domain .

The "openId-provider-example" has the following settings :

We have generated a x.509 certificate from the provider (nothing too special we generated the cert-request in the page, then signed it using a dummy Cert Authority and loaded the certificate back in, another note is that the certificate here is not the same certificate as used by the Ag/SPS httpd webserver to do SSL).

We are only signing the ID Token, a byproduct of signing the user information was the data appears as based64 (presumably pkcs#7 blob) in the the trace log files.

In the case we worked though with we were testing the claims and scope mappings. By default quite a number of claims are generated, but in our testing we removed the generated ones and then had to add some back in - so your claims may look a little different.

That was all that was needed for OIDC Provider Setup.

5) Setup OIDC Client

The OIDC client setup was also fairly easy. From Federation/Clients menu we clicked "Create Client".

The Client ID and Secret are generated and we need those latter when we setup the actual client side in the Apache 24.

That is all that is needed for the OIDC Client setup.

6) Install Apache 2.4 on Win2012 :

We are using mod_auth_openidc in Apache24 as the OIDC client The install and running on Win2012 comes with a few hickups, so I thought I'd cover those, and how we worked through them.

When we tried to start apache we get the following error (I doctored the screenshot here, since I had lostthe orignal error, but it was something like):

Ok, so that is not unusual, we have already loaded a version of the MS Visual Studio runtime, but each compiled object can be dependant on difference versions of the MSVC runtime.

Here, it seems apache httpd.exe was built with Visual Studio 2017, so we have already loaded the 2017 redistributable runtime vc_redist64.exe. But mod_auth_openidc.so was compiled with Visual Studio 2013, so it needs the 2013redistributable runtime package as well as the 2017 one.

A google search for the msvcp120.dll will quickly give you the right vc redist package .exe that you need to install.

Load MSVC dependency for mod_auth_openidc.

MSVC120.dll is from Visual Studio 2013,and the redist package is available from here:

Retest Apache again - seems we are not finished with dependency problems as yet.

This one was a bit harder to resolve. Fortunately using dependency walker (I've added a bit more notes in an appendix on how to use this ) we can see below that mod_auth_openidc.so, loads libcurl.dll and libcurl.dll want to load the OpenSSL libraries libeay32.dll and ssleay32.dll.

8) Configure test dumpenv.bat to show our HTTP header variables.

The dumpenv.bat run is really only for demonstration purposes. Generally on a production server you do not want to allow execution of .bat files, nor do you want to be dumping all the server environment variables - so this is strictly for demonstration/test purposes - to show that the header variables are set when passed through the Apache24 client.

We add a cgi-script handler for .bat and +ExecCGI to the main Directory setting, which then encompasses the example subdirectory.

It was recommended to disabled the mapping of DOS executable formats to downloads in the mime.types file to allow them to be executed.

Add dumpvars.bat file to the htdocs/example directory :

The dumpvars.bat script is not too complicated, for cgi scripts the header variables are set as HTTP_environment variables so the script just does a "set" to dump all environment variables. Better scripts can be done in perl, python, java and .net, but this was what we had available to us with a simple Apache24 setup:

(a .zip file of the examples directory including the dumpvars.bat file is attached to the post).

also, I noticed we need to copy all the DLL's from mod_auth_openidc-2.3.2-apache-2.4.x-win64.zip\Apache24\bin to \apache24\bin also all these DLL's needs to be available in c:\windows\system32 folder too.

The .dll's usually just need to be in the directory your are running from or in a directory on the PATH. In my case I copied them into the apache24\bin directory.

Yeah but the main trick was dependency walker to find what dll's you needed. And the fact that it was a 64bit program, but making call to 32bit openssl dll's. In the old days 32bit -> 61bit that was called thunking I don't know what trick they pull now to do 64bit -> 32bit call, but that was the dependency.

I do find Linux dependencies are easier to manage, since they are all 64bit, and the OS distribution provides them.

Hi Vikas, the XXXX I am fairly sure is just masking out the value, it was a while ago I did this work.

For the 401 Access denied response, you will need to check the logs on the server where the request as made, presumably the failed request was made from the browser to either the apache or the SPS server, or it was made via backchannel call from the apache via to SPS server.

So presumably the SPS will have an access_log with the request and 401 response and you can check the webagenttrace.log or FWSTrace.log (and them possibly the policy server trace log) to see why request was not authorized.

In the article, it mentions setting up /affwebservices/secure/secureredirectas the only protected resource - I know a few people missed that step, but I don't think that results in a 401 result.

I could find none. Hence I am assuming something extra is being done. Does you OP (CA SSO) configuration match what is presented as screenshots in the blog above ?

Could you change the error_log to debug level and see what is happening on "mod_auth_openidc" end. Paste your debug lines from apache error_logs. I am assuming it is failing at the authorization code acceptance process itself, thus no further calls (back channel calls).

Alternatively have you tried regenerating your ClientSecret and using the new ClientSecret on "mod_auth_openidc".