skip to Main Content

We have a requirement to support SAML for SSO (Okta and Google). I have been able to set up my own custom SAML application in Google and configure mellon in apache. However, we have a requirement to configure SAML in Okta for customers and SAML in Google for our internal users.

#################################################################################

# Global configuration for mod_auth_mellon.

# This configuration is shared by every virtual server and location in this instance of apache.

#################################################################################

# MellonCacheSize sets the maximum number of sessions which can be active at once. When mod_auth_mellon reaches this limit, it will begin removing # the least recently used sessions. The server must be restarted before any changes to this option takes effect.

# Default: MellonCacheSize 100

MellonCacheSize 100


# MellonLockFile is the full path to a file used for synchronizing access to the session data. The path should only be used by one instance of apache at a time.The server must be restarted before any changes to this option takes effect.

# Default: MellonLockFile "/var/run/mod_auth_mellon.lock"

MellonLockFile "/var/run/mod_auth_mellon.lock"


# MellonPostCount is the maximum amount of saved POST requests

# Default: MellonPostCount 100

MellonPostCount 100

###########################################################################

# End of global configuration for mod_auth_mellon.

###########################################################################

<Location />
        MellonEnable "info"
        Require valid-user
        AuthType "Mellon"
        MellonVariable "cookie"
        MellonSamlResponseDump On
        MellonSPPrivateKeyFile /etc/apache2/googlesaml/mellon.key
        MellonSPCertFile /etc/apache2/googlesaml/mellon.crt
        MellonSPMetadataFile /etc/apache2/googlesaml/mellon_metadata.xml
        MellonIdPMetadataFile /etc/apache2/googlesaml/GoogleIDPMetadata.xml
        MellonEndpointPath /mellon
        MellonDefaultLoginPath /
        RequestHeader set MELLON_NAME_ID %{MELLON_NAME_ID}e
</Location>

<VirtualHost *:443>
   ServerName host_name
   DocumentRoot /var/www/html
   SSLEngine on
   SSLCertificateFile  /etc/ssl/certs/server.pem
   SSLCertificateKeyFile /etc/ssl/private/private.key

 <Location />
          AuthType Mellon
          MellonEnable auth
            Require valid-user
 </Location>
 <Location /protected>
     AuthType Mellon
      MellonEnable auth
      Require valid-user
 </Location>
</VirtualHost>

How can we differentiate incoming request between Okta and Google (SAML) as Location /> directive can be configured by only either one of SAML provider.

2

Answers


  1. Chosen as BEST ANSWER

    I have tried below config and it works for openidc and mellon both. Apparently, this scenario would be helpful for those willing to configure Okta (mellon) and google sso for internal IDP.

    <Location />
             MellonEndpointPath /mellon/
             MellonSPMetadataFile /etc/apache2/saml/mellon_metadata.xml
             MellonSPPrivateKeyFile /etc/apache2/saml/mellon.key
             MellonSPCertFile /etc/apache2/saml/mellon.crt
             MellonIdPMetadataFile /etc/apache2/saml/idp_metadata.xml
             MellonVariable "mellon_cookie"
             MellonDefaultLoginPath /
             MellonSecureCookie on
    </Location>
    <VirtualHost *:443>
       ServerName zzz.xxxx.com
       SSLEngine on
       SSLCertificateFile  /etc/ssl/certs/xxxxx_prod.pem
       SSLCertificateKeyFile /etc/ssl/private/xxxxx.com.key
       OIDCResponseType "id_token"
       OIDCScope "openid email profile"
       OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
       OIDCRedirectURI "https://zzz.xxxx..com/openidc_callback"
       OIDCDiscoverURL https://zzz.xxxx.com/idp-discovery.html
       <Location /uliya>
             AuthType "mellon"
             Require valid-user
             MellonEnable "auth"
        </Location>
       <Location /transport>
          AuthType openid-connect
          Require valid-user
          OIDCUnAuthAction auth
       </Location>
       <Location "/idp-page.html">
          Require all granted
       </Location>
    </VirtualHost>
    

  2. The mod_auth_mellon module only applies SAML to a specific <Location />...</Location>, so you would have to configure a location for each idP provider.

    <VirtualHost *:443>
       ServerName host_name
       DocumentRoot /var/www/html
       SSLEngine on
       SSLCertificateFile  /etc/ssl/certs/server.pem
       SSLCertificateKeyFile /etc/ssl/private/private.key
    
     # GoogleSaml
     <Location />
        MellonEnable "info"
        Require valid-user
        AuthType "GoogleSaml"
        MellonVariable "cookie"
        MellonSamlResponseDump On
        MellonSPPrivateKeyFile /etc/apache2/googlesaml/mellon.key
        MellonSPCertFile /etc/apache2/googlesaml/mellon.crt
        MellonSPMetadataFile /etc/apache2/googlesaml/mellon_metadata.xml
        MellonIdPMetadataFile /etc/apache2/googlesaml/GoogleIDPMetadata.xml
        MellonEndpointPath /mellon
        MellonDefaultLoginPath /
        RequestHeader set MELLON_NAME_ID %{MELLON_NAME_ID}e
     </Location>
     
     # Okta
     <Location /protected>
        Require valid-user
        AuthType "OktaSaml"
        MellonEnable "auth"
        MellonDecoder "none"
        MellonVariable "cookie"
        MellonSecureCookie On
        MellonUser "NAME_ID"
        MellonSetEnv "e-mail" "mail"
        MellonEndpointPath "/endpoint"
        MellonDefaultLoginPath "/"
        MellonSessionLength 300
        MellonSPPrivateKeyFile /etc/apache2/mellon/http_192.168.14.130_okta.key
        MellonSPCertFile /etc/apache2/mellon/http_192.168.14.130_okta.cert
        MellonIdPMetadataFile /etc/apache2/mellon/metadata
        MellonSamlResponseDump On
        MellonSessionDump On
     </Location>
    </VirtualHost>
    

    If you want to do this dynamically based on the user’s headers, I wouldn’t recommend mod_auth_mellon, having your application serve up the authentication would make more sense.

    Hope this helps.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search