OpenSAML user discussion

["Pantvaidya, Vishwajit" <>]

Thanks a lot, Scott.

 

On a different note, I see following snippet in the pseudocode:

 

// get the decrypter (it's hardcoded to use Inline key resolver

BasicCredential credential = new BasicCredential();

credential.setPrivateKey(@get the private key to be used for this request possibly configured based on where the request is coming from@);

Decrypter decrypter = new Decrypter(null, new StaticKeyInfoCredentialResolver(credential), new InlineEncryptedKeyResolver());

...

// or retrieve first encrypted assertion and decrypt it to get the assertion

List<EncryptedAssertion> encAssertions = samlResponse.getEncryptedAssertions();

EncryptedAssertion encAssertion = encAssertions.get(0);

Assertion assertion = decrypter.decrypt(encAssertion);

Configuration.getMarshallerFactory().getMarshaller(assertion).marshall(assertion);

 

 

It seems to be using a private key to decrypt the assertion.

1.    Shouldn’t a public key be used instead of a private key?

2.    Are assertions usually decrypted, even when https is used?

 

 

Thanks,

 

Vish.

 

-----Original Message-----
From: Scott Cantor [mailto:]
Sent: Monday, October 27, 2008 11:48 AM
To:
Subject: RE: [OpenSAML] Migrating to opensaml 2.2.0

 

> [Pantvaidya, Vishwajit] Thanks Scott. I do understand XMLSchema. If it is

> not too painful, please feel free to post the differences.

 

SAML 1.0 doesn't have XML ID attributes in the schema. In 1.1, the schema

was modified to make the AssertionID and related attributes actual IDs. As a

result, mixing them is impossible in validating applications, and signing is

essentially unusable in SAML 1.0.

 

There's nothing good about what was done, it was a mistake from day one and

then compounded by changing the schema. People should avoid using SAML 1.x

at all unless they have to use it, and should never use SAML 1.0 anywhere

now. If you can't upgrade from it now, whatever is requiring SAML 1.0 is

probably orphaned anyway and should be put down like a rabid animal.

Security software that isn't being maintained is a threat.

 

> Else, when I get

> the time, I will look up the SAML 1 v/s 1.1 differences from the spec. So

> for now, what I understand is that, when I use the classes from the saml1

> pacjages, I am conforming to SAML1.1. Is that right?

 

By default, perhaps, but in general it's whatever you set MinorVersion to.

There is no sense of conformance in those classes, they handle both versions

either well or badly, but not separately.

 

-- Scott