Demo - SiteMinder Provider and sample OIDC Client
search cancel

Demo - SiteMinder Provider and sample OIDC Client

book

Article ID: 440314

calendar_today

Updated On:

Products

SITEMINDER

Issue/Introduction

You need to integrate an OpenID Connect (OIDC) client application with SiteMinder acting as the Authorization Provider. You require a definitive list of configuration parameters and prerequisites to ensure successful federation, specifically for environments running SiteMinder 12.8 SP7.

Environment

Authorization Provider:

  • Product: SiteMinder
  • Version: 12.8 SP7 and higher
  • OS: Red Hat Enterprise Linux (RHEL) 9 / CentOS 9 Stream

 

OpenID Connect (OIDC) client application:

  • Product: httpd + mod_auth_openidc
  • OS: Red Hat Enterprise Linux (RHEL) 9 / CentOS 9 Stream

 

In this demo,

[Authorization Provider]
Name: SiteMinderProvider
Authorization Provider Base URL: https://siteminder.example.com --> referred as {ProviderBaseURL}

[OIDC Client App]
Name: sampleclient --> referred as {ClientName}
OIDC Client Base URL: https://oidc.example.net --> referred as {ClientBaseURL}
Redirect_URI: {ClientBaseURL}/protected/redirect_uri

 

Cause

This is a guide for the mandatory parameters and environment settings required when SiteMinder serves as the OIDC Provider (OP) for an external or third-party OIDC Client.

Resolution

You must collect specific details from the OIDC client application team and ensure the SiteMinder environment meets the persistent storage requirements.

1. Information to Collect from the OIDC Client Application

Before configuring the partnership in SiteMinder, you obtain the following from the client application team:

  • Redirect URIs: A complete list of authorized callback URLs where SiteMinder sends authorization codes or tokens. Note that wildcards are not supported in 12.8 SP7. 
  • Grant Types: The specific OIDC flows the client requires (e.g., Authorization Code, Implicit, or Refresh Token).
  • Scopes: The scopes the client requests (e.g., openid, profile, email) and any custom claims required for mapping.
  • Client Authentication Method: How the client authenticates to the token endpoint (e.g., client_secret_post or client_secret_basic).
  • Application Type: Whether the application is "Confidential" (server-side) or "Public" (SPA/Mobile).

2. SiteMinder Provider Configuration Requirements

You verify and apply these settings on the SiteMinder side:

  • Session Store: You must configure a persistent session store. OIDC tokens in SiteMinder require persistent storage to function.
  • Authentication URL: Set this to a persistent realm (e.g., {ProviderBaseURL}/affwebservices/redirectjsp/redirect.jsp) to ensure the user session is properly stored.
  • Agent Configuration Object (ACO) Update: You must remove /. from the BadURLChars parameter. If left in, SiteMinder blocks the {ProviderBaseURL}/affwebservices/CASSO/oidc/{ClientName}/.well-known/openid-configuration Metadata URL, which causes the integration to fail.
  • OIDC Logout: Native OIDC logout is not supported in version 12.8 SP7. You use the standard SiteMinder LogOffURI in the ACO for session termination.
  • Certificates: Use certificates issued by a Certificate Authority (CA). Many OIDC modules, such as mod_auth_openidc, do not trust self-signed certificates by default. Certificate Chain to be provided to the OIDC Client side to import so it can establish secure backchannel communicationi to the Provider.

3. Configuration Visual Aids

To assist with the implementation, you can refer to the following configuration samples:

Authorization Provider(SiteMinder):

AdminUI --> Federation --> OpenID Connect --> Authorization Provider.

 

AdminUI --> Federation --> OpenID Connect --> Clients

 

4. Client-Side Implementation (Example: mod_auth_openidc)

To assist with the implementation, you can refer to the following configuration samples:

OpenID Connect Client(mod_auth_openidc):

Document Root is set to /var/www/mysite and has header_info.php to dump headers.

If you use the mod_auth_openidc module on an Apache server, you configure the following in your auth_openidc.conf:

  • OIDCRedirectURI: Matches the URI registered in SiteMinder.
  • OIDCProviderMetadataURL: The discovery URL provided by SiteMinder (e.g., {ProviderBaseURL}/affwebservices/CASSO/oidc/{ClientName}/.well-known/openid-configuration).
  • OIDCClientID and OIDCClientSecret: Values randomly generated during client registration in the SiteMinder AdminUI.

In this demo, the configuration file is "/etc/httpd/conf.d/auth_openidc.conf" file

[root@oidc conf.d]# grep ^OIDC auth_openidc.conf
OIDCRedirectURI https://oidc.example.net/protected/redirect_uri
OIDCCryptoPassphrase ############################################
OIDCProviderMetadataURL https://siteminder.example.com/affwebservices/CASSO/oidc/sampleclient/.well-known/openid-configuration
OIDCClientID 000a42b9-5e8c-1a01-9376-ef90c0a80000
OIDCClientSecret ########################################

And the LoadModule is configured in "/etc/httpd/conf.modules.d/10-auth_openidc.conf"

[root@oidc conf.modules.d]# cat 10-auth_openidc.conf
LoadModule auth_openidc_module modules/mod_auth_openidc.so

And the "/protected/" location must be protected using the oidc module.

I am using "/etc/httpd/conf.d/ssl.conf"

[root@oidc conf.d]# cat ssl.conf
#
# When we also provide SSL we have to listen to the
# standard HTTPS port in addition.
#
Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
###   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec##
## SSL Virtual Host Context
##<VirtualHost _default_:443># General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/mywebsite"
ServerName oidc.example.net:443
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn  auth_openidc_module:trace5

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   List the protocol versions which clients are allowed to connect with.
#   The OpenSSL system profile is used by default.  See
#   update-crypto-policies(8) for more details.
#SSLProtocol all -SSLv3
#SSLProxyProtocol all -SSLv3

#   User agents such as web browsers are not configured for the user's
#   own preference of either security or performance, therefore this
#   must be the prerogative of the web server administrator who manages
#   cpu load versus confidentiality, so enforce the server's cipher order.
SSLHonorCipherOrder on

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
#   The OpenSSL system profile is configured by default.  See
#   update-crypto-policies(8) for more details.
SSLCipherSuite PROFILE=SYSTEM
SSLProxyCipherSuite PROFILE=SYSTEM

#   Point SSLCertificateFile at a PEM encoded certificate.  If
#   the certificate is encrypted, then you will be prompted for a
#   pass phrase.  Note that restarting httpd will prompt again.  Keep
#   in mind that if you have both an RSA and a DSA certificate you
#   can configure both in parallel (to also allow the use of DSA
#   ciphers, etc.)
#   Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
#   require an ECC certificate which can also be configured in
#   parallel.
#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /etc/httpd/conf/server.crt
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
#   ECC keys, when in use, can also be configured in parallel
#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/httpd/conf/server.key
#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convenience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
SSLCACertificateFile /etc/httpd/conf/ca-bundle.crt

#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<Location />
#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
#            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
#           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
SSLOptions -StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
    <Directory /var/www/mywebsite>
        AllowOverride All
        Options Indexes FollowSymLinks
        AddHandler php74-fcgi .php
        Action application/x-httpd-php /usr/lib64/apache2/modules/libphp.so
        DirectoryIndex index.php index.html header_info.php
    </Directory>
    <Location /protected/>
        AuthType openid-connect
        Require valid-user
    </Location>

#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is sent or allowed to be received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is sent and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly.
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"</VirtualHost>

* Provider's Certificate Chain to be imported in to the local certificate store.

In this case, the CA Certificate is imported(appended) to SSLCACertificateFile "/etc/httpd/conf/ca-bundle.crt"

Also, imported to "/etc/pki/ca-trust/source/anchors/Provider-CA.crt" and run "update-ca-trust extract"

A test from OIDC Client machine "curl {ProviderBaseURL}/affwebservices/CASSO/oidc/sampleclient/.well-known/openid-configuration" must return a JSON response.

 

5. Test

Access {ClientBaseURL}/protected/

Get redirected to Provider's authorize endpoint --> Authentication URL --> Authenticate --> Authentication URL --> authorize endpoint

Redirect to Redirect_URI --> Land at target page.

OIDC_CLAIM_email        : [email protected]
OIDC_CLAIM_family_name  : SN User1
OIDC_CLAIM_given_name   : GivenNameUser1
OIDC_CLAIM_phone_number : 0123456789
OIDC_CLAIM_initials     : U1
OIDC_CLAIM_sub          : user1

 

Powered by Wolken Software