External IdP

[Grady]

Hello,

Looking to bring in an external IdP for SSO.  Plan is to use Keycloak ( http://www.keycloak.org/ ) which is SAML 2.0 compliant.

Checking the docs, I see this limitation documented at the the end of the IdP section:

Identity Provider Limitations 

The internal Identity Provider solution should be used in favor of any external solutions until the IdP Service Provider fully satisfies the SAML 2.0 Web SSO profile

However, if I look in JIRA, I see that this issue: https://codice.atlassian.net/browse/DDF-1519 - Create an IdP and SP to satisfy the SAML 2 Web SSO profile

With acceptance criteria of:

Conform to SAML 2 specifications

integration tests

document how to connect external IdP/SP

It is marked as Fixed.  Is this a case of OBE documentation or is the IdP Service Provider not yet fully compliant with SAML 2.0 WSSO?

Thanks in Advance.

[Scott Tustison]

Hi Grady,

Our IdP and SP are SAML 2.0 compliant. The documentation is referring to the fact that not all of the options have been satisfied. The current 2.10.0 release of DDF only supports POST and Redirect methods from the browser. The SOAP authentication method is supported through the use of SAML ECP to authenticate non-person entities. In our experience, each IdP and SP combination has some quirks and slightly different interpretations of the spec. We have not tried keycloak, though I'll add it to my list of different solutions to try out when I get around to it. Assuming they conform to the spec, it should work.

Scott

[Grady]

Hello,

Getting back at trying to hook an external IDP (keycloak) to DDF.  Currently have 2.10.3 deployed.  DDf is getting hung up when validating the AuthN response pushing out an exception like this:

2017-08-03 15:39:40,418 | INFO  | tp1754960400-621 | IdpHandler | .client.AssertionConsumerService  307 | 427 - security-idp-client -.saml2.core.impl.IssuerImpl@2ea22ad3

ddf.security.samlp.ValidationException: Invalid or untrusted signature.

        at org.codice.ddf.security.idp.client.AuthnResponseValidator.validate(AuthnResponseValidator.java:67)[427:security-idp-client:2.10.3]

        at org.codice.ddf.security.idp.client.AssertionConsumerService.validateResponse(AssertionConsumerService.java:305)[427:security-idp-client:2.10.3]

        at org.codice.ddf.security.idp.client.AssertionConsumerService.processSamlResponse(AssertionConsumerService.java:249)[427:security-idp-client:2.10.

        at org.codice.ddf.security.idp.client.AssertionConsumerService.processSamlResponse(AssertionConsumerService.java:299)[427:security-idp-client:2.10.

        at org.codice.ddf.security.idp.client.AssertionConsumerService.postSamlResponse(AssertionConsumerService.java:128)[427:security-idp-client:2.10.3]

I added some further debugging statements to SimpleSign to try to tease out a bit more information about why it thinks the signature is invalid/untrusted.  This is the causing exception:

2017-08-03 15:39:40,414 | WARN  | tp1754960400-621 | SimpleSign | ddf.security.samlp.SimpleSign     294 | 209 - security-core-api - 2

org.apache.wss4j.common.ext.WSSecurityException: No message with ID "certpath" found in resource bundle "org/apache/xml/security/resource/xmlsecurity"

        at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:836)[133:org.apache.wss4j.wss4j-ws-security-common:2.1.7]

        at org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(SignatureTrustValidator.java:108)

        at org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:64)

        at ddf.security.samlp.SimpleSign.validateSignature(SimpleSign.java:292)[209:security-core-api:2.10.3]

        at org.codice.ddf.security.idp.client.AuthnResponseValidator.validate(AuthnResponseValidator.java:63)[427:security-idp-client:2.10.3]

        at org.codice.ddf.security.idp.client.AssertionConsumerService.validateResponse(AssertionConsumerService.java:305)[427:security-idp-client:2.10.3]

        at org.codice.ddf.security.idp.client.AssertionConsumerService.processSamlResponse(AssertionConsumerService.java:249)[427:security-idp-client:2.10.

        at org.codice.ddf.security.idp.client.AssertionConsumerService.processSamlResponse(AssertionConsumerService.java:299)[427:security-idp-client:2.10.

        at org.codice.ddf.security.idp.client.AssertionConsumerService.postSamlResponse(AssertionConsumerService.java:128)[427:security-idp-client:2.10.3]

Any thoughts on where I should be looking?

Thanks in advance.

[Grady]

For those coming after me, if you see the message:

org.apache.wss4j.common.ext.WSSecurityException: No message with ID "certpath" found in resource bundle "org/apache/xml/security/resource/xmlsecurity"

The way I fixed that was by importing Keycloaks Realm certificate into DDF's keystore.

Related question:

What should be in the RelayState when redirecting the SAMLResponse back to /services/saml/sso?  From the ddf source, looks like the url to redirect to?  Anything else needed?

[Scott Tustison]

The relaystate token is supposed to just be an opaque token that the IdP returns to the SP. What is in it is entirely up to the SP. We do put the redirect URL into it so that we don't need to maintain any state. This is a pretty common practice.

[Grady]

Scott,

I have DDF and Keycloak working together to provide auth/auth for DDF deployments.   I had to make minor changes to the DDF code base in order to get it to work.   Would like to offer the modifications with the intent of getting this capability rolled into the next release.    

I have the changes in a fork here:  https://github.com/codice/ddf/compare/ddf-2.10.3...gradygit:external_idp

Was hoping you could review and provide what the next steps should be.  

Thanks.

[Brendan Hofmann]

Grady,

Thanks for getting back to us! Would you mind submitting a pull request with your changes so that we can review it more easily?