OpenSAML user discussion

[Brent Putman <>]

Title: decrypting EncryptedAssertion in Browser Post profile use case

Singh, Manish wrote:

finally it worked last night and yes it was a silly mistake.

 

Good, glad it worked.

I added some more docs to the Decrypter Javadocs on the component arguments that you asked about.  Hopefully their usage should be more clear now.

Brent: could you do me a favor and take a look at this code for verifying signature.

I assembled it from bits and pieces from opensaml unit test and javadocs.

It works fine but is there a better (assuming this is just a test code and will be reorganized) approach(in my use case saml response is signed).

 

DefaultBootstrap.bootstrap();

 

 BasicSAMLMessageContext messageContext = new BasicSAMLMessageContext();
 messageContext.setInboundMessageTransport(new HttpServletRequestAdapter(request));

 

 BasicParserPool parser = new BasicParserPool();
 parser.setNamespaceAware(true);
   
    SAMLMessageDecoder decoder = new HTTPPostDecoder(parser);
    decoder.decode(messageContext);

 

 Response samlResponse = (Response)messageContext.getInboundMessage();
 Signature signature =  samlResponse.getSignature();

 

 Certificate certificate = ks.getCertificate("pi");
 PublicKey publicKey = certificate.getPublicKey();

 

 BasicCredential credential = new BasicCredential();
 credential.setPublicKey(publicKey);

 

 SignatureValidator signatureValidator = new SignatureValidator(credential);
 signatureValidator.validate(signature);

This looks functionally correct, although it's the lowest level, "manual" way you could do things.  If you do it this way, I would add a validation of the signature with the SAMLSignatureProfileValidator from java-opensaml2 prior to the cryptographic validation of the signature, just to be safe.

You're basically hardcoding trusted key resolution for signature validation to a single relying party (whoever owns that "pi" cert).  Which is fine, as long as that assumption holds (probably not very long).  Presumably you want to support more than one identity provider?

A more advanced approach would take advantage of the Decoder and MessageContext capabilities to process the message, which can include a lot of the security stuff like this.  A MessageContext can take a SecurityPolicyResolver which resolves SecurityPolicy(s) and validates the message context with them.  A SecurityPolicy consists of SecurityPolicyRules.

An example of a SecurityPolicyRule is the SAMLProtocolMessageXMLSignatureSecurityPolicyRule in java-opensaml2, which validates the signature on the protocol message.  Rules like this typically contain a TrustEngine.  There are for example SignatureTrustEngine impls which take care of both cryptographically validating the Signature and establishing trust of the validation key.  Information used for trust establishment can come from a resolver of some kind, such as a CredentialResolver which resolves trusted credentials. 

A common source of trusted information in the SAML 2 world would be SAML 2 metadata, for which we have a resolver for trusted credentials.


Yes, that's a lot of stuff, but it's not overwhelmingly complicated.  That's just a quick overview.  There are examples of most of these things in the unit tests.  If you want to see a full-blown example of how things are intended to get processed in this model, you could take a look at the Shibboleth 2.0 IdP (the java-idp project in our SVN).  Look at the profile handlers in package edu.internet2.middleware.shibboleth.idp.profile.saml2.  That's an IdP, not an SP like I infer you are doing, but the use of the message context, security rules and policy, etc is going to be very similar.

If you think our conversation could be useful to others too, then we can post these at the wiki.

Yes, I hope to have more of the signature and encryption topics documented in the wiki near future (next few weeks).


--Brent