Symantec Access Management

CA SSO OpenID Connect Provider - with Apache OpenID Client 

09-22-2017 02:04 AM

Note: This article describes using an Apache OpenIDC client with SSO OpenIDC Provider.  Later I wrote a follow up article, where we used an SSO OAuth2 client to connect to the same SSO OpenIDC Provider. That article is here:  SSO Client Federation Partnership to SSO OpenIDC Provider 



As a follow up to jack.saunders Jack Saunders, excellent run book for setting up SSO OpenID Connect Provider 12.7

CA SSO OpenID Connect Provider - Agentless SSO 


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 not an SSO setup (that will have to be a latter article). Here the OpenID Client is Apache httpd with mod_auth_openidc module.


1) Prerequisites: 


Policy Server R12.7 


Access Gateway R12.7 


Apache httpd webserver with mod_auth_openidc installed.


2) Test Case & Example: 


OpenIDC Client  :

OpenIDC Connect Provider :


So we access URL in the the openIDC client side: 

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


After successull login we are then redirected back to the client 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 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 create a SSO domain SPSTest to contain the policy:

Here we picking the UserStore where we want the users to logon from.


The SSO domain has realms, the important one being the  /affwebservices/secure/secureredirect realm where we have indicated our OpenIDC Connect Provider will use:


The /affwebservices/secure/secureredirect realm, contains our Access Gateway webagent (here called agent) :

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:


For the one rule "AllowGetPost" for the realm, we have set it up as a regular expression, using a wildcard, to give effective protected resource for :* 

The policy for the SSO Domain is also fairly simple:  We allow all uses in the 'UserDir" User Store :

For the Policy rules that are checked we pick the AllowGetPost rule for the realm /affwebservices/secure/secureredirect 


So effectively any user from the 'UserDir' can access the realm  /affwebservices/secure/secureredirect once they are logged on.  The policy setup is now complete. 


Note: It is important that the URL 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. 


We can test the policy setup via access : 

which should then prompt us for credentials from our UserDir.

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 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.


First we installed the binary pre-build apache24. install From:

Then unzipped and move the expanded directory to c:\Apache24: 


Install the recommended Redistributable MSVC++ VC libraries redist64.exe.

It was pretty simple, from apachelounge they recommended: 

Be sure !! that you have installed the latest C++ Redistributable Visual Studio 2017 : vc_redist_x64 or vc_redist_x86.

Depending on what you have previously loaded you may already have these C/C++ compiler redist libraries loaded. 


We will come back to redist libraries a bit latter - but this step works fine.


Run quick test to see that Apache works : 

Run Apache from the cmd line to check that the basic install works. 




So we now have a basic Apache installed and running.


6) Install module mod_auth_openidc module into Apache24 :

For OIDC client we install the module and install that into our Apache setup. 


Download openidc windows install .zip: 

Download the windows install (most of the linux installs are clearly going to be easier) : 


Expand the mod_auth_openidc zip file: 


Copy openidc to the apache 2.4 directories:

Copy modules/ to the c:\Apache24\modules directory, and the bin/libcurl.dll etc. to the c:\Apache24\bin directories.


Modify httpd.conf to load mod_auth_openidc. 

Change Apache24/conf/httpd.conf entry to load module : 


Re-test Apache with Install mod_auth_openidc - first error - missing msvc dependency

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 was compiled with Visual Studio 2013, so it needs the 2013 redistributable 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: 


We download and install this re-dist 64 bit package.


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, loads libcurl.dll and libcurl.dll want to load the OpenSSL libraries libeay32.dll and ssleay32.dll.  

DLL Dependency via Dependency Walker ( ) : 

For Linux these extra libraries are distributed by the vendor, but for Windows that is not the case.  From the : the two sites to download openssl windows binaries:


But before getting to those, I had got my answer from here : 

64bit - Enable cURL on PHP7 windows10 64 bit Apache 2.4 - Stack Overflow 

Essentially downloading the php that matches the apache2.4 VC15 distribution, and copying libeay32.dll libssh2.dll and ssleay32.dll into apache/bin directory.


Re-test Apache with installed mod_auth_openidc + openssl libraries - now working 

Finally our run of Apache from the cmd line to check that the basic install works! 





So now we have Apache24 running with loaded module.


7) Configure OIDC Apache2.4 Client 


The OIDC parameters are fairly simple copy, as setup by Jack, with the values I've generated for my connect provider.  

We turned off SSLValidation, since we are using a non standard Cert Issuer on and for our signing certificate.

The Provider URL's all come from the OIDC setup in the SSO Policy Server.

We added the OIDCClientID and OIDCSecret as per the SSO Policy Server OIDC CLient setup.

We added the OIDCScope and OIDCProviderUserInfoEndpoint as that was needed to get the additional user attributes, using the attributes we had defined in the SSO Policy Server OIDC Client setup.

And at the bottom we setup the /example Location as protected by our openid-connect. scheme.


Here is a copy of the raw values: 

OIDCSSLValidateServer Off
OIDCClientID d7017955-83ce-4b58-87ed-1aa2851a9154
OIDCClientSecret vW2wJ1LJX0xM/aBgm50nuluQNmCr83tv6qO35iEQr5s=
OIDCCryptoPassphrase SomePassword
OIDCProviderTokenEndpointAuth client_secret_post
OIDCScope "openid email fullname userDetail"


And the /example location protected by openid-connect : 

<Location /example/>
AuthType openid-connect
Require valid-user


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).


9) References:


1 Favorited
2 Files
zip file   381 B   1 version
Uploaded - 05-29-2019
zip file   6 KB   1 version
Uploaded - 05-29-2019

Tags and Keywords


03-20-2018 07:55 AM



NOTE : Please open a new thread and reference this blog as a link whilst asking a question on the new thread. 


Would we by any luck have a fiddler trace of where the request is looping ? We need to see if the request is looping within OP or is it looping between OP and RP. Both have different & multiple error possibilities. Hence if we know where to focus, it'd be better to pick up the discussion from there.

03-20-2018 07:52 AM



NOTE : Please open a new thread and reference this blog as a link whilst asking a question on the new thread. 


1. Are you sure SSL (https) is enabled on CA AG.


2. Please check the Apache (As RP) configuration if you have defined the URL on https.


03-20-2018 05:26 AM

Thanks for this guide.

I think I'm now at the final stage.

If I see looping the login screen, what may be the cause of looping?

I found the following entries in policy server trace log:


[03/20/2018][09:01:15.901][09:01:15][12570][140275405661952][Sm_Auth_Message.cpp:4900][CSm_Auth_Message::SendReply][s147/r156][ag03win][][superuser][][/affwebservices/secure/secureredirect][openidconnect2][ForwardInc][][][][][][][][][][][][][** Status: Authenticated. ]




[03/20/2018][09:01:15.903][09:01:15][12570][140275388876544][Sm_Az_Message.cpp:598][CSm_Az_Message::SendReply][s147/r157][ag03win][][superuser][][/affwebservices/secure/secureredirect][openidconnect2][][][][][][][][][][][][][][** Status: Authorized. ]




[03/20/2018][09:01:15.963][09:01:15][12570][140275388876544][SmAuthorization.cpp:588][CSmAz::IsProtected][][][/affwebservices/casso/oidc/authorize?smassertionref=query&smassertionref=query&smassertionref=query&response_type=code&scope=openid&client_id=0001649f-a975-1ab0-ac26-80b50aa05a5a&state=v5g5h-kajvhsfzmpyjafpmeizsk&][][][][][][][][][][65536][][][][][][][][Resource is not protected, no realm matches this resource]




Do you think what I'm forgetting to do?




03-15-2018 07:22 PM



I followed the above instructions now I am getting the below error.



OpenID Connect Provider error: invalid_request




Network trace.


I noticed it is not redirect from /affwebservices/CASSO/oidc/authorize to /affwebservices/secure/secureredirect.


Any suggestions?



02-16-2018 10:00 AM

I searched in my working setup (apache error logs : debug level) for these strings. My setup is all Linux. Unless Windows prints different than Linux.


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".




02-15-2018 11:12 PM

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. 


Cheers - Mark 

02-15-2018 03:31 PM

Hi Mark.ODonohue I am getting error on OIDC side, any insights for this error?


Configuration and Log files

OIDCSSLValidateServer Off
OIDCClientID f7c1a70c-d17a-4ecb-933b-40c0e0ea5a6a
OIDCClientSecret vb2ydAmyut0CpH1kKEcDph7c0fAv8VsFmGHfj+pnVa4=
OIDCCryptoPassphrase testpassword
OIDCProviderTokenEndpointAuth client_secret_post
OIDCScope "openid name"

**please note I am getting ClientID and ClientSecret from OAuthProvider server which cannot be decrypted.


[Thu Feb 15 17:50:36.134424 2018] [auth_openidc:error] [pid 3404:tid 952] [client] oidc_util_decode_json_object: JSON parsing returned an error: '[' or '{' expected near '<' (\r\n<TITLE>401: Access Denied</TITLE>\r\n\r\n

401: Access Denied

[Thu Feb 15 17:50:36.134424 2018] [auth_openidc:error] [pid 3404:tid 952] [client] oidc_proto_resolve_code_and_validate_response: failed to resolve the code


==============Browser Error===============

OpenID Connect Provider error: Error in handling response type.


Also, in FWSTrace.log I see


[02/15/2018][20:00:22][4780][3588][112bb02e-8fe1d886-e59923f7-9c6e8495-855fafe7-a73a][][processAuthorization][Received the following code from authorization code generator: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXQT0=]
[02/15/2018][20:00:22][4780][3588][112bb02e-8fe1d886-e59923f7-9c6e8495-855fafe7-a73a][][sendResponse][Sending response:
[02/15/2018][20:00:22][4780][3588][112bb02e-8fe1d886-e59923f7-9c6e8495-855fafe7-a73a][][sendResponse][Redirecting to redirect URL:]


Code is showing as XXXXXXXX is this expected? this code is hidden?

02-14-2018 05:13 PM

I am fairly sure I got my OpenSSL windows binaries from here : 

Binaries - OpenSSLWiki 


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. 


Cheers - Mark

02-14-2018 02:42 PM

Hi Mark.ODonohue

Thanks for this detailed step by step document to configure OIDC

I found the below link to downloading libeay32.dll libssh2.dll and ssleay32.dll


Miroslav Novák - OpenSSL DLLs for Total Commander - … 


also, I noticed we need to copy all the DLL's from\Apache24\bin to \apache24\bin also all these DLL's needs to be available in c:\windows\system32 folder too.

Related Entries and Links

No Related Resource entered.