Splunkweb SSO – SAMLv2

SAMLv2 becoming the de facto standard for achieving the Single Sign On (SSO) across the disparate  business systems. Splunkweb SSO solution relies on the proxy layer of the front end web container. Recently I have invested some time to figure out how one can accomplish Splunkweb SSO by leveraging the identity  contained in a SAMLv2  assertion. In this article I am going to give a run down of how to perform Splunkweb SSO by authenticating to a SAMLv2 compliant identity provider(IdP). I assume the reader is familiar with the federated identity terminologies, such a IdP,Service Provider(SP), Circle of Trust(CoT) etc., and Splunkweb SSO concepts. This is a follow on my earlier Splunkweb SSO blog entry.

Prerequisites

In order to honor the SAMLv2 authentication, splunkweb relies the authentication be handled by the proxy layer. To vlaidate this scenario I have used the httpd proxy plugin along with the mod_auth_mellon module on Linux system. Here are the requirements

  • mod_auth_mellon-0.6.0
  • Lasso  release-2.2.2 http://lasso.entrouvert.org/
  • httpd server httpd-2.2.24
  • Splunk Version 5.x+
  • OpenAM 10.1.x – SAMLv2  IdP
  • OpenLDAP 2.4

The setup and configuration details are omitted for brevity, if you have questions feel free to contact me.

How it works.?

The  splunkweb is fronted by a reverse proxy plugin enabled http server. This apache httpd server is also enabled with mod_auth_mellon-0.6.0, this is the key piece that enable the proxy server to behave like SAMLv2 service provider(SP). When the user access the splunkweb URL via the proxy server it redirects the authentication to the SAMLv2 identity provider (IdP) upon successful authentication it sets the HTTP request header, that will be passed on to the splunkd  for authorization(authz). When splunkd authorizes the identity contained in the header it lets the user access the splunkweb dashboards based on the level authorization.

Note that the SSO solution still relying on the HTTP request header values because the authorization is still performed by splunkd based on the LDAP strategy configuration and its role/LDAP group mappings. Even though it is technically possible for splunkd to consume the SAMLv2 assertion and directly pull the authz information from the attribute query statements, in essence Splunk itself playing the SP role. As of Splunk 5.0, this feature is not embedded in the core splunkd server. This means still you need to create a LDAP strategy along with necessary group/role mappings for the authorization purposes, you must be using the same LDAP  identity store that SAMLv2 identity provider is using for authentication. Alternatively you can create a file based authz store which may not scale for   large deployments, besides it poses identity management inconsistencies.

Configuring SAMLv2 Identity Provider

OpenAM is one of most popular easy to use open source identity provider that supports all the federation and web services security standards. With its intuitive user interface one can quickly configure the circle of trusts and meta data exchange.

Step1 : Create the metadata of Service Provider(Apache Proxy)

In this case apache reverse proxy  along with mod_auth_mellon plugin acts like a service provider(that consume the SAMLv2 assertion from IdP). You need to exchange the meta data from IdP and SP so the the trust is established. To create the SP meta data issue the following command

./mellon_create_metadata.sh urn:splunkweb:proxy.splunkweb.com https://proxy.splunkweb.com:18888/secret/endpoint Output files: Private key: urn_splunkweb_proxy.splunkweb.com.key Certificate: urn_splunkweb_proxy.splunkweb.com.cert Metadata: urn_splunkweb_proxy.splunkweb.com.xml Host: proxy.splunkweb.com:18888 Endpoints: SingleLogoutService: https://proxy.splunkweb.com:18888/secret/endpoint/logout AssertionConsumerService: https://proxy.splunkweb.com:18888/secret/endpoint/postResponse

This will create the meta data that you need to send it to the IdP(in this case OpenAM).  Upload the file urn_splunkweb_proxy.splunkweb.com.xml in to the OpenAM as part of the

remote service provider setup. The script mellon_create_metadata.sh shipped with the mod_auth_mellon plugin.

Step 2: Setup the hosted identity provider at the IdP

Setup and  configure  the OpenAM identity provider that support SAMLv2 protocol.

Step 2a. Creating the Service Provider configuration

Make sure the  IdP and the SP belong to the same circle of trust. Otherwise your would notice problems in  getting the authentication.

make sure the providers are in the same CoT

Step3: Obtain the IdP meta data

http://idp.saml2.com:48080/openam/saml2/jsp/exportmetadata.jsp

it is a xml that you need to save and copy to the proxy server. it must be copied to the location pointed by the httpd.conf  property MellonIdPMetadataFile.(in this case it is: idp-meta.xml)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EntityDescriptor entityID="http://idp.saml2.com:48080/openam" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09w
ZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAK
BgNVBAoTA1N1bjEQMA4GA1UECxMHT3BlblNTTzENMAsGA1UEAxMEdGVzdDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEArSQc/U75GB2AtKhbGS5piiLkmJzqEsp64rDxbMJ+xDrye0EN/q1U5Of+
RkDsaN/igkAvV1cuXEgTL6RlafFPcUX7QxDhZBhsYF9pbwtMzi4A4su9hnxIhURebGEmxKW9qJNY
Js0Vo5+IgjxuEWnjnnVgHTs1+mq5QYTA7E6ZyL8CAwEAATANBgkqhkiG9w0BAQQFAAOBgQB3Pw/U
QzPKTPTYi9upbFXlrAKMwtFf2OW4yvGWWvlcwcNSZJmTJ8ARvVYOMEVNbsT4OFcfu2/PeYoAdiDA
cGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC
/FfwWigmrW0Y0Q==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/ArtifactResolver/metaAlias/i
dp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://idp.saml2.com:48080/openam/IDPSloRedirect/metaAlias/idp" ResponseLocation="http
://idp.saml2.com:48080/openam/IDPSloRedirect/metaAlias/idp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://idp.saml2.com:48080/openam/IDPSloPOST/metaAlias/idp" ResponseLocation="http://idp.s
aml2.com:48080/openam/IDPSloPOST/metaAlias/idp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/IDPSloSoap/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://idp.saml2.com:48080/openam/IDPMniRedirect/metaAlias/idp" ResponseLocation="http
://idp.saml2.com:48080/openam/IDPMniRedirect/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://idp.saml2.com:48080/openam/IDPMniPOST/metaAlias/idp" ResponseLocation="http://idp.s
aml2.com:48080/openam/IDPMniPOST/metaAlias/idp"/>
<ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/IDPMniSoap/metaAlias/idp"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</NameIDFormat>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://idp.saml2.com:48080/openam/SSORedirect/metaAlias/idp"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://idp.saml2.com:48080/openam/SSOPOST/metaAlias/idp"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/SSOSoap/metaAlias/idp"/>
<NameIDMappingService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/NIMSoap/metaAlias/idp"/>
<AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://idp.saml2.com:48080/openam/AIDReqSoap/IDPRole/metaAlias/idp"/>
<AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="http://idp.saml2.com:48080/openam/AIDReqUri/IDPRole/metaAlias/idp"/>
</IDPSSODescriptor>
</EntityDescriptor>

Step 4: Structure of SP meta data

Following is the meta data that we used to create the SP at the IdP side.  Basically the content of the file  urn_splunkweb_proxy.splunkweb.com.xml

<EntityDescriptor entityID="urn:splunkweb:proxy.splunkweb.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

    <KeyDescriptor use="signing">

      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

        <ds:X509Data>

          <ds:X509Certificate>MIICxDCCAawCCQDamCVi//0j5jANBgkqhkiG9w0BAQUFADAkMSIwIAYDVQQDExlw

cm94eS5zcGx1bmt3ZWIuY29tOjE4ODg4MB4XDTEzMDMyODE4MjI0MloXDTIzMDMy

ODE4MjI0MlowJDEiMCAGA1UEAxMZcHJveHkuc3BsdW5rd2ViLmNvbToxODg4ODCC

ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANeXJapDGjylWI8TEBACKJl6

t11yyexKiMmy5Dx3LsGFmXLhjSmjY+UAXLfHo2+UBgsR+/Zjkxhzafk5FyOl0xHN

1Q+DCy8vnMiIn1SYZFKhqPiWoMEGqATjHBMnDgbkoleJ2M3vUtU3J/9cgWNyH1tu

Oe0cW6sr0ktavmLGwR248EZ4vIGNGIGLfn5VguCwLQmkNCT6imyJnIP4gf0NBd7M

UDv+eeevXQunhiBdJYG0VGkFkwPUaHVGai6FF/twOSaDfkhrhxn+mUje8gj7U8ej

Frul1pIdFqajHB2+vEUjf0d5D+K+kk81BcDKt/+MQWgXJ0z6AyudvOBlXBORASkC

AwEAATANBgkqhkiG9w0BAQUFAAOCAQEAY6IImiv0WA8IQXL2sXMb5tZCfkzjiUcF

mg8uIfbokUiSc/FW1wdSFhdxJpISgvH0FzIOvo1htK8JBJNrITqguV9l3R8JvM1e

bH4bYi3lceEJ2hIaYzMAtJLhFu/GU7ypbfFBb5YPrMWbeBBYHAiRfAtj/2+OGVwD

xahM5K7mZemMWsYhGU/9/HKnROqbNMw2bmgmOwSbqrSgXG4QWt7YoGJwfvKEiHcP

mQdmYb7lmHPt0HYra2nTOwxrAPH2BFS8ZBsMOiuUuRGNYwy6Zm98Ulrxc6zXAoEV

OhmHNuUIqzUy3BFDvilja+gYdM0zpoFdcgKH4zYicrBhiO84CsaWxw==</ds:X509Certificate>

        </ds:X509Data>

      </ds:KeyInfo>

    </KeyDescriptor>

    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://proxy.splunkweb.com:18888/secret/endpoint/logout"/>

    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://proxy.splunkweb.com:18888/secret/endpoint/postResponse" index="0"/>

  </SPSSODescriptor>

</EntityDescriptor>

Configuration in httpd.conf

The changes that we need to make in the proxy server’s httpd.conf is the key  for making this whole thing to work.  We have to make configuration changes specific to

  • mod_auth_mellon
  • Setting HTTP header for Splunkweb consumption
<Location />
# Add information from the auth_mellon session to the request.
MellonEnable "auth"
Require valid-user
AuthType "Mellon"
MellonVariable "cookie"
MellonSamlResponseDump On
# Configure the SP metadata
# This should be the files which were created when creating SP metadata.
MellonSPPrivateKeyFile  /home/ithangasamy/sso/webserver-18787/secret/endpoint/urn_splunkweb_proxy.splunkweb.com.key
MellonSPCertFile  /home/ithangasamy/sso/webserver-18787/secret/endpoint/urn_splunkweb_proxy.splunkweb.com.cert
MellonSPMetadataFile /home/ithangasamy/sso/webserver-18787/secret/endpoint/urn_splunkweb_proxy.splunkweb.com.xml
# IdP metadata. This should be the metadata file you downloaded from the IdP.
MellonIdPMetadataFile /home/ithangasamy/sso/webserver-18787/secret/endpoint/idp-meta.xml
MellonUser "common-name"  #this is the property coming on the SAML assertion set as REMOTE_USER
#MellonUser "username"
# The location all endpoints should be located under.
# It is the URL to this location that is used as the second parameter to the metadata generation script.
# This path is relative to the root of the web server.
MellonEndpointPath /secret/endpoint
#Options +FollowSymLinks
RewriteEngine on
RewriteRule .* - [E=RU:%{REMOTE_USER}]
RequestHeader set X_REMOTE_USER %{RU}e
</Location>

This completes the  configuration at the proxy layer to make the SAMLv2 authentication.

Splunk Configurations

In order to leverage the SAMLv2 authentication, we need to make changes in the web.conf and server.conf, these changes are pretty much same as the normal SSO configuration.

Here is how my web.conf looks

[settings]
root_endpoint=/dashboard
trustedIP=127.0.0.1,10.1.42.3,10.160.255.80,10.160.22.159
remoteUser=X-Remote-User
SSOMode=permissive


Create the LDAP strategy for Authorization

Create an LDAP strategy pointing to the LDAP identity store that is used by the SAMLv2 identity provider. If you dont do this, you have to create a file based authz store. In my case I did create a OpenLDAP identity store for authz.

Testing the SSO

Restart the proxy and try to access the proxy url https://proxy.splunkweb.com:18888/dashboard this will redirect to the SAMLv2 identity, if not you likely have a configuration problem.

Note that it is not redirecting to the splunkweb authentication screen but to your SAMLv2 IdP to perform the SAMLv2 authentication. once authenticated, it sets the REMOTE_USER header with the common-name that is sent in the SAML response, as you can see below in the SAML response. In this manner you can fetch any  identity attribute via the SAML assertion.

SAML Authn Request

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_2286F0395BA0D4F069827C5662387ACB"
                    Version="2.0"
                    IssueInstant="2013-03-29T01:32:27Z"
                    Destination="http://idp.saml2.com:48080/openam/SSORedirect/metaAlias/idp"
                    Consent="urn:oasis:names:tc:SAML:2.0:consent:current-implicit"
                    ForceAuthn="false"
                    IsPassive="false"
                    >
    <saml:Issuer>urn:splunkweb:proxy.splunkweb.com</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                        AllowCreate="true"
                        />
</samlp:AuthnRequest>

SAML Response

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                ID="s2bbdefafc8cb45f00dde8a20486666536e05722f3"
                InResponseTo="_2286F0395BA0D4F069827C5662387ACB"
                Version="2.0"
                IssueInstant="2013-03-29T01:32:59Z"
                Destination="https://proxy.splunkweb.com:18888/secret/endpoint/postResponse"
                >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.saml2.com:48080/openam</saml:Issuer>
    <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                          Value="urn:oasis:names:tc:SAML:2.0:status:Success"
                          />
    </samlp:Status>
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="s2af66e31879b77dc124f9e1dbcca3ec40b225a1f0"
                    IssueInstant="2013-03-29T01:32:59Z"
                    Version="2.0"
                    >
        <saml:Issuer>http://idp.saml2.com:48080/openam</saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
                                           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                                           />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
                                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                                    />
                <ds:Reference URI="#s2af66e31879b77dc124f9e1dbcca3ec40b225a1f0"
                              xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                              >
                    <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"
                                      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                                      />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
                                      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                                      />
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                                     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                                     />
                    <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">REQOzSZGtUauSsWrhsW90SSI4Qo=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
hG9MyE1+CD/1BwAiXNtkJhqDlErz31gmeWf+iFoWwny3Sn1deN1gDuE9P40rzyd0WAP+IXhSlmHE
rtRKiM9kW5xnvMDI/gx3aCvCWxik7hGGFSVkuH/sTYGMy5sFwJSlqFS3tuc2orzzW8f5VxvHSegF
AlSbdO8ED9fjrEiweyE=
</ds:SignatureValue>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                    <ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MIICQDCCAakCBEeNB0swDQYJKoZIhvcNAQEEBQAwZzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMQwwCgYDVQQKEwNTdW4xEDAOBgNVBAsTB09w
ZW5TU08xDTALBgNVBAMTBHRlc3QwHhcNMDgwMTE1MTkxOTM5WhcNMTgwMTEyMTkxOTM5WjBnMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExDDAK
BgNVBAoTA1N1bjEQMA4GA1UECxMHT3BlblNTTzENMAsGA1UEAxMEdGVzdDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEArSQc/U75GB2AtKhbGS5piiLkmJzqEsp64rDxbMJ+xDrye0EN/q1U5Of+
RkDsaN/igkAvV1cuXEgTL6RlafFPcUX7QxDhZBhsYF9pbwtMzi4A4su9hnxIhURebGEmxKW9qJNY
Js0Vo5+IgjxuEWnjnnVgHTs1+mq5QYTA7E6ZyL8CAwEAATANBgkqhkiG9w0BAQQFAAOBgQB3Pw/U
QzPKTPTYi9upbFXlrAKMwtFf2OW4yvGWWvlcwcNSZJmTJ8ARvVYOMEVNbsT4OFcfu2/PeYoAdiDA
cGy/F2Zuj8XJJpuQRSE6PtQqBuDEHjjmOQJ0rV/r8mO1ZCtHRhpZ5zYRjhRC9eCbjx9VrFax0JDC
/FfwWigmrW0Y0Q==
</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                         NameQualifier="http://idp.saml2.com:48080/openam"
                         >6GPF1vsjVlu6pzY23dnQVJUYIloL</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData InResponseTo="_2286F0395BA0D4F069827C5662387ACB"
                                              NotOnOrAfter="2013-03-29T01:42:59Z"
                                              Recipient="https://proxy.splunkweb.com:18888/secret/endpoint/postResponse"
                                              />
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2013-03-29T01:22:59Z"
                         NotOnOrAfter="2013-03-29T01:42:59Z"
                         >
            <saml:AudienceRestriction>
                <saml:Audience>urn:splunkweb:proxy.splunkweb.com</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2013-03-29T01:32:59Z"
                             SessionIndex="s2aad88fb61f474b8309100d12f410971960050401"
                             >
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
        <saml:AttributeStatement>
            <saml:Attribute Name="common-name">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                     xsi:type="xs:string"
                                     >indira thangasamy</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

as you can see the authenticated identity’s common name is being sent in the response, you can retrieve any userprofile attribute via the attribute statement including the group membership information.

and here is how the SSO related properties looks like

Single Logout – SLO

To perform the  single logout(to destroy the SAML  session), mod_Auth_mellon provides the end point under the proxy, for example following invocation will kill the SAML session https://proxy.splunkweb.com:18888/secret/endpoint/logout?ReturnTo=https://proxy.splunkweb.com/logout_success.html

here is the logout response from the IdP.

<samlp:LogoutResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                      ID="s185cd8d4f0fbb6e545e7522a685cd142caf8ebbf"
                      Version="2.0"
                      IssueInstant="2013-03-29T02:13:07Z"
                      Destination="https://proxy.splunkweb.com:18888/secret/endpoint/logout"
                      InResponseTo="_A0722D2519C4A64420262824C4CBFF12"
                      >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.saml2.com:48080/openam</saml:Issuer>
    <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                          Value="urn:oasis:names:tc:SAML:2.0:status:Success"
                          />
    </samlp:Status>
</samlp:LogoutResponse>

Conclusion

It is a short version of a long story, with in the SAMLv2 you can do signing/encryption, IdP initiated SSO and many more. For the SSO usecase we have used the Browser POST profile for SSO and Browser Artifact profile for the SLO.  This can be extended to address other use cases as well.

Acknowledgments

I gratefully acknowledge the people who created and shared the following  technology add-ons

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*