Shibboleth SP – Signing and Encryption Key

encryptionshibboleth

I have a Shibboleth SP installed on Server 2012 R2. I tried to submit the metadata to be imported into the IDP and was told that without having the signing or encryption key, they won't be able to send the SP any assertions.

From what I've found on this, Shibboleth SP has the key to use included in the default installation. I believe that is the sp-cert.pem and the sp-key.pem included in the C:\opt\shibboleth-sp\etc\shibboleth folder.

I'm not sure how to reference it in the Shibboleth2.xml file either.
Here is my shibboleth2.xml as of right now:

<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"    
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
logger="syslog.logger" clockSkew="180">

<!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
<OutOfProcess logger="shibd.logger">

</OutOfProcess>

<!-- The InProcess section conrains settings affecting web server modules/filters. -->
<InProcess logger="native.logger">
    <ISAPI normalizeRequest="true">

        <Site id="1" name="sp-example.com"/>
    </ISAPI>
</InProcess>


<!-- This set of components stores sessions and other persistent data in daemon memory. -->
<StorageService type="Memory" id="mem" cleanupInterval="900"/>
<SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="mem"/>
<ArtifactMap artifactTTL="180"/>



<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
<RequestMapper type="Native">
    <RequestMap applicationId="default">
        <Host name="sp-example.com" authType="shibboleth" requireSession="true"/>

    </RequestMap>
</RequestMapper>


<ApplicationDefaults id="default" policyId="default"
    entityID="urn:mace:university.edu:shibboleth:test:sp:university:administrative:cscn:sp-example.com"
    homeURL="https://sp-example.com"
    REMOTE_USER="eppn persistent-id targeted-id"
    signing="false" encryption="false"
    >


    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
        handlerURL="/Shibboleth.sso" handlerSSL="true"
        exportLocation="http://sp-example.com/Shibboleth.sso/GetAssertion" exportACL="165.91.23.32"
        idpHistory="false" idpHistoryDays="7" cookieProps="https" >


        <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                relayState="cookie" entityID="urn:mace:university.edu:shibboleth:test:idp:university:administrative:cscn:idp-test.university.edu">
            <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
            <SessionInitiator type="Shib1" defaultACSIndex="5"/>
        </SessionInitiator>

        <md:AssertionConsumerService Location="/SAML2/POST" index="1"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
        <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
        <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
        <md:AssertionConsumerService Location="/SAML/POST" index="5"
            Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
        <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
            Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>

        <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
        <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
            <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
            <LogoutInitiator type="Local"/>
        </LogoutInitiator>

        <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
        <md:SingleLogoutService Location="/SLO/SOAP"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
        <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
        <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

        <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
        <md:ManageNameIDService Location="/NIM/SOAP"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
        <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
        <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>


        <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

        <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
        <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

        <!-- Status reporting service. -->
        <Handler type="Status" Location="/Status" acl="127.0.0.1"/>

        <!-- Session diagnostic service. -->
        <Handler type="Session" Location="/Session" showAttributeValues="false"/>

    </Sessions>


    <Errors session="sessionError.html"
        metadata="metadataError.html"
        access="accessError.html"
        ssl="sslError.html"
        localLogout="localLogout.html"
        globalLogout="globalLogout.html"
        supportContact="root@localhost"
        logoLocation="/shibboleth-sp/logo.jpg"
        styleSheet="/shibboleth-sp/main.css"/>


    <!-- Chains together all your metadata sources. -->
    <MetadataProvider type="Chaining">
        <!-- Example of remotely supplied batch of signed metadata. -->
        <MetadataProvider type="XML" uri="https://idp-test.university.edu/universityfed-test-metadata-signed.xml"
             backingFilePath="C:\opt\shibboleth-sp\etc\shibboleth\universityfed-test-metadata-signed.xml" reloadInterval="7200">
        </MetadataProvider>
    </MetadataProvider>

    <!-- Chain the two built-in trust engines together. -->
    <TrustEngine type="Chaining">
        <TrustEngine type="ExplicitKey"/>
        <TrustEngine type="PKIX"/>
    </TrustEngine>

    <!-- Map to extract attributes from SAML assertions. -->
    <AttributeExtractor type="XML" path="attribute-map.xml"/>

    <!-- Use a SAML query if no attributes are supplied during SSO. -->
    <AttributeResolver type="Query"/>

    <!-- Default filtering policy for recognized attributes, lets other data pass. -->
    <AttributeFilter type="XML" path="attribute-policy.xml"/>


</ApplicationDefaults>

<!-- Each policy defines a set of rules to use to secure messages. -->
<SecurityPolicies>
    <!-- The predefined policy enforces replay/freshness and permits signing and client TLS. -->
    <Policy id="default" validate="false">
        <Rule type="MessageFlow" checkReplay="true" expires="60"/>
        <Rule type="ClientCertAuth" errorFatal="true"/>
        <Rule type="XMLSigning" errorFatal="true"/>
        <Rule type="SimpleSigning" errorFatal="true"/>
    </Policy>
</SecurityPolicies>

According to an email I recieved, I need to include <md:KeyDescriptor use="encryption"> and <md:KeyDescriptor use="signing">

From what I found online, it should be something similar to:

<md:SPSSODescriptor>
<md:KeyDescriptor>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
            <ds:X509Certificate>
                hash found in sp-cert.pem file
            </ds:X509Certificate>
        </ds:X509Data>
    </ds:KeyInfo>
</md:KeyDescriptor>

I don't know where I should be putting this in the Shibboleth.xml file.

Can anybody help to get me on the right track? I have been through a decent amount of documentation and guides from different institutions, but haven't found any direction.

Best Answer

The answer was to add the following line to the Shibboleth2.xml (in the ApplicationDefaults section):

<CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>

sp-key.pem and sp-cert.pem are included in the Shibboleth installation. They are located in the same folder as the Shibboleth2.xml file.

I also changed the line:

<ApplicationDefaults id="default" policyId="default" entityID="urn:mace:university.edu:shibboleth:test:sp:university:administrative:cscn:sp-example.com"
    homeURL="https://sp-example.com"
    REMOTE_USER="eppn persistent-id targeted-id"
    signing="false" encryption="false"
    >

To:

<ApplicationDefaults id="default" policyId="default"
 entityID="urn:mace:university.edu:shibboleth:test:sp:university:administrative:cscn:sp-example.com"
    homeURL="https://sp-example.com"
    REMOTE_USER="eppn persistent-id targeted-id"
    signing="true" encryption="true"
    >

When the line is added, the Metadata has entries for for the certs and needs to be reimported to the IDP.

Related Solutions

SSH Key – How to Create a Public Key from a Private Key

Use the -y option to ssh-keygen:

ssh-keygen -f ~/.ssh/id_rsa -y > ~/.ssh/id_rsa.pub

From the 'man ssh-keygen'

 -y      This option will read a private OpenSSH format file and print an
         OpenSSH public key to stdout.

Specify the private key with the -f option, yours might be dsa instead of rsa. The name of your private key probably contains which you used. The newly generated public key should be the same as the one you generated before.

MySQL Encryption and Key management

There aren't really any built-in MySQL features for handling sophisticated encrypted key setups. You'll need to implement the bulk of the encryption logic in your own PHP and/or browser-side (javascript?) code.

But your stated concerns are slightly peculiar: It seems like your only real concerns are a SQL injection or brute force (password-guessing, I assume) attack from a remote client desktop/laptop workstation. That makes me suspect that you already have some other, un-mentioned security measures planned, and you've analysed the possible avenues of compromise.

For one, I'm assuming you have firewall rules protecting the MySQL/PHP host against any kind of access from unapproved remote client IPs. If I'm correct, it makes sense that you're only worried about attacks from compromised users' workstations.
Also, I'm assuming you understand that if an attacker on the remote client host can escalate to root/Admin privs, or directly compromise the real user's own account, then that client's data has zero protection regardless of encryption or any other safeguards. (The attacker can read the keys from wherever they're saved on disk, or snoop them as the real user enters them at logon, and keys lead to data.)

Starting from those two assumptions, it makes sense for us to conclude that the only two relevant threats are A) brute-force password guessing, and B) SQL injection attempts:

If the attacker doesn't get ahold of the real user's key, or if he wants access to more than just the real user's data, he can try brute-forcing logon creds for the real user or another account. (In theory you could lock down each account to a specific remote client IP, which would help compartmentalize the risks, too.)
If the attacker does get a valid key for the real user, he has an avenue past the logon screen (which is presumably simple enough to be secure), to the soft underbelly of the potentially buggy app code. A successful SQL injection from the real user's context could give him access to other clients data, too.

Now, let's talk about how server-side encryption applies to these situations:

Server-side encryption definitely helps against the SQL injection threat. If the row values are encrypted in the DB tables, the attacker can only see gibberish ciphertext of the data that belongs to other accounts. The threat is contained, compartmentalized.
Brute forcing password guessing, though, doesn't really get any harder for an attacker facing server-side encryption. Regardless of whether the users' keys are stored on the server or generated on-the-spot from the password, the only thing that matters is whether you have the right password. Either the server decides to let you use the valid stored key because it checks that your password is correct, or it calculates the valid key for you because your password is the correct input to generate that key.

Client side encryption, on the other hand, actually makes brute force password attacks irrelevant. You can't brute-force a properly constructed key. Client-side encryption keeps basically the same level of protection against SQL injection as server-side encryption, too. The client can pass the key to the server at logon, keeping a copy in memory until the session finishes, which puts the crypto CPU burden on the server. Or, the client can handle the encryption/decryption by itself, in the browser. There are ups and downs to both techniques:

Passing its key to the server is far easier to code and manage, and usually much faster on account of more optimized crypto code (compiled C, probably).
A pure client-side approach gives extra security, because even if an attacker gets root on the server, he still can't read the encrypted data, and he never will be able to read it. The only possible attack vector is to compromise the remote client workstation.

Finally, I'm going to note that there are some huge operational downsides to encrypting data in the database. Because the encrypted data representations are essentially random patterns, basic database features like indexing, joins, etc. aren't going to work. The client takes on a huge logic burden, and may lose a lot of the benefits that database features normally bring.

Best Answer

Related Solutions

SSH Key – How to Create a Public Key from a Private Key

MySQL Encryption and Key management

Related Topic