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 : http://www.demo.com/example/
OpenIDC Connect Provider : http://www.example.com/affwebservices/secure/secureredirect
So we access URL in the the openIDC client side:
http://www.demo.com/example/dumpvars.bat
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 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 : https://ww.example.com/affwebservices/secure/secureredirect*
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 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.
We can test the policy setup via access : http://www.example.com/affwebservices/secure/secureredirect/
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 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.
First we installed the binary pre-build apache24. install From: http://www.apachelounge.com/download/
https://github.com/pingidentity/mod_auth_openidc/releases
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 mod_auth_openidc.so 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) :
https://github.com/pingidentity/mod_auth_openidc/releases
Expand the mod_auth_openidc zip file:
Copy openidc to the apache 2.4 directories:
Copy modules/mod_auth_openidc.so 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 mod_auth_openidc.so 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 mod_auth_openidc.so 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:
https://www.microsoft.com/en-us/download/details.aspx?id=40784
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 mod_auth_openidc.so, loads libcurl.dll and libcurl.dll want to load the OpenSSL libraries libeay32.dll and ssleay32.dll.
DLL Dependency via Dependency Walker ( http://www.dependencywalker.com/ ) :
For Linux these extra libraries are distributed by the vendor, but for Windows that is not the case. From the : https://wiki.openssl.org/index.php/Binaries the two sites to download openssl windows binaries:
https://slproweb.com/products/Win32OpenSSL.html
https://indy.fulgan.com/SSL/
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 mod_auth_openidc.so 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 www.example.com connect provider.
We turned off SSLValidation, since we are using a non standard Cert Issuer on https://ww.example.com 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
OIDCProviderIssuer https://www.example.com
OIDCClientID d7017955-83ce-4b58-87ed-1aa2851a9154
OIDCClientSecret vW2wJ1LJX0xM/aBgm50nuluQNmCr83tv6qO35iEQr5s=
OIDCProviderAuthorizationEndpoint https://www.example.com/affwebservices/CASSO/oidc/authorize
OIDCProviderTokenEndpoint https://www.example.com/affwebservices/CASSO/oidc/token
OIDCRedirectURI http://www.demo.com/example/redirect
OIDCCryptoPassphrase SomePassword
OIDCProviderTokenEndpointAuth client_secret_post
OIDCProviderJwksUri https://www.example.com/affwebservices/CASSO/oidc/jwks?AuthorizationProvider=openId-provider-example
OIDCScope "openid email fullname userDetail"
OIDCProviderUserInfoEndpoint https://www.example.com/affwebservices/CASSO/oidc/userinfo
# https://github.com/pingidentity/mod_auth_openidc/blob/master/auth_openidc.conf
And the /example location protected by openid-connect :
<Location /example/>
AuthType openid-connect
Require valid-user
</Location>
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: