litsec / opensaml-ext Goto Github PK

The ContactPersonFactoryBean gives NPE - not initialized correctly.

There are several Litsec open source libraries built upon OpenSAML 3.4.0. When we run Snyk on those we have had to exclude a number of dependencies that we get from OpenSAML's dependencies since Snyk reports vulnerabilities.

We need to introduce a dependency BOM that takes care of this for us centrally.

Working with the opensaml-ext is too heavy since it also holds a huge number of HTML-files since I added mirroring of OpenSAML API-doc. Let's move that to another repo ...

If the idpList(String completeUri, IDPEntry... idpEntries) method of the se.litsec.opensaml.saml2.core.build.ScopingBuilder class is invoked with a null argument for completeUri the resulting element will look like:

<saml2p:Scoping xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml2p:IDPList>
            <saml2p:IDPEntry
                ProviderID="http://id.swedenconnect.se/eidas/1.0/proxy-service/se" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"/>
            <saml2p:GetComplete/>
        </saml2p:IDPList>
    </saml2p:Scoping>

The <saml2p:GetComplete/> should not be there.

If the update or sign methods are called from several threads at the same time we risk ending up with bad signatures.

Processing of a SAML response follows some well-defined steps. We should add a bean that does this work ...

The implementation of the ResponseProcessor interface, se.litsec.opensaml.saml2.common.response.ResponseProcessorImpl does not supply the expected issuer of the response being validated. This leads to log warnings.

The validateResponse method should be updated and the expected issuer should be installed to the ResponseValidationParameters.

If the resource given to SpringResourceMetadataProvider is packaged as a resource in a jar file, the constructor will say that the file can not be found. This is because the constructor invokes the super constructor (FilesystemMetadataProvider) and calls resource.getFile().

Validation of assertions has been improved in OpenSAML 4. Let's update our implementations accordingly.

In the constructor of RedirectRequestHttpObject the code section:

    Endpoint endpointObject = ObjectUtils.createSamlObject(Endpoint.class);
    endpointObject.setBinding(this.getBindingURI());
    endpointObject.setLocation(endpoint);

does nothing except cause a crash since there is no builder for the Endpoint class registered (it is abstract).

Upgrade dependencies to latest OpenSAML version (3.4.2).

The OpenSAML-code of the HTTPRedirectDeflateEncoder calculates the signature of query-parameters belonging to the SingleSignOnService URL of the IdP. Section 3.4 of SAMLBind states that those parameters should be excluded from the signature calculation.

This bug affects the AbstractRequestGenerator that needs to implement a work-around for the bug.

When using an AuthnRequestGenerator that returns an PostRequestHttpObject the sendUrl is encoded for inclusion in an HTML attribute (i.e., as value for an input element). This is not correct since the value should be used as the POST action in a form.

Snyk reports the following vulnerabilities for the opensaml-ext dependencies:

HIGH SEVERITY:

Unexpected Code Execution
Vulnerable module: org.bouncycastle:bcprov-jdk15on
Introduced through: org.opensaml:[email protected], org.opensaml:[email protected] and others.

MEDIUM SEVERITY:

Deserialization of Untrusted Data
Vulnerable module: com.google.guava:guava
Introduced through: net.shibboleth.utilities:[email protected] and com.google.guava:[email protected]

MEDIUM SEVERITY:

Insecure Encryption
Vulnerable module: org.bouncycastle:bcprov-jdk15on
Introduced through: org.opensaml:[email protected], org.opensaml:[email protected] and others

In the code creating signed AuthnRequest messages (and other request messages) we should consider the peer's metadata entry and honor the <alg:SigningMethod> and <alg:DigestMethod> elements (if any).

Today the signature algorithm is statically configured.

OpenSAML defines the class org.opensaml.xmlsec.config.impl.DefaultSecurityConfigurationBootstrap which is a class the provides OpenSAML defaults for crypto algorithms. These algorithms differ a bit compared to the ones suggested in SAML2Int (https://kantarainitiative.github.io/SAMLprofiles/saml2int.html#_cryptographic_algorithms).

We should introduce the class Saml2IntSecurityConfigurationBootstrap that provides defaults that are in line with SAML2Int.

Add easy to use methods for adding <md:EncryptionMethod>, <alg:SigningMethod> and <alg:DigestMethod> elements to metadata.

Section 2.7.3.1.1 of SAML Core says:

If the data content of an element is of an XML Schema
simple type (such as xs:integer or xs:string), the datatype MAY be
declared explicitly by means of an xsi:type declaration in
the element.

The AttributeUtils class is a bit picky about that the type should be present. We should relax this.