Encryption

[Lohr, Donald]

We are in conversation with an integrator of a cloud app ( I can not
disclose yet) and we asked the following question, and their answer is
in red.
/
Does the vendor support full endpoint-to-endpoint XML (assertion)
encryption via the use of a certificate model, compatible with the model
supported by Shibboleth? If not, how does the vendor provide
confidentiality between endpoints, or does the vendor expect a custom
setting in the RelyingParty configuration that sets
encryptAssertions=”never”? //This is coming up more and more now
(especially within the university system). We do not support XML
assertion encryption at this time. We do support x509 signature and
certificate validation on all responses, but not assertion encryption.

/For starters, my Shibboleth 2.x knowledge is very limited, I'm a
newby. The above question is from a previous Shibboleth admin. I do not
fully understand this question we asked the integrator.

My question for the group, does Shibboleth 2.x support x509 signature
and certificate validation.

I need to be able to get some reasonable comment back to my manager on
the answer the integrator provided.

Thanks
//

[Cantor, Scott]

Post by Lohr, Donald
Does the vendor support full endpoint-to-endpoint XML (assertion)
encryption via the use of a certificate model, compatible with the model
supported by Shibboleth?

We don't have our own model for this, it's simply required by SAML
implementations. All standard. Just for the record. When communicating
with vendors, it's usually best to not even mention Shibboleth at all
because it biases them with excuses about how we must be doing
non-standard things.

Post by Lohr, Donald
For starters, my Shibboleth 2.x knowledge is very limited, I'm a newby.
The above question is from a previous Shibboleth admin. I do not fully
understand this question we asked
the integrator.

SAML long ago deprecated the back-channel as an exchange path. Your
assertion travels from the IdP through the browser to the SP. The data
there is readable. XML Encryption makes it much harder to read if there's
malware in the client.

Post by Lohr, Donald
My question for the group, does Shibboleth 2.x support x509 signature and
certificate validation.

Yes, but the IdP isn't validating the signature, it's creating it. And you
don't want the vendor doing X.509 anything, you want them pulling the key
out of the certificate you give them or from the metadata if by some
miracle they support metadata, and using that directly. The workaround for
them not doing that is using long-lived certificates that are self-signed
to prevent mistakes.

-- Scott

[Tom Scavo]

(just adding two cents to what Scott said)

Post by Cantor, Scott

Post by Lohr, Donald
For starters, my Shibboleth 2.x knowledge is very limited, I'm a newby.
The above question is from a previous Shibboleth admin. I do not fully
understand this question we asked
the integrator.

SAML long ago deprecated the back-channel as an exchange path. Your
assertion travels from the IdP through the browser to the SP. The data
there is readable. XML Encryption makes it much harder to read if there's
malware in the client.

So, for the SP to fully support XML Encryption in multilateral
fashion, three requirements must be met:

1) The SP must publish its encryption certificate in metadata (which
the IdP uses to encrypt the assertion over the wire).

2) The SP must be configurable with the corresponding private key (so
that it can decrypt assertions received from the IdP).

3) The SP must be simultaneously configurable with TWO private keys,
which are tried in turn until a successful decryption occurs.

This last capability is often overlooked. Without it, an SP is unable
to safely rollover an encryption certificate in metadata, in which
case the relationship between IdP and SP is reduced to a manual,
bilateral arrangement.

Post by Cantor, Scott

Post by Lohr, Donald
My question for the group, does Shibboleth 2.x support x509 signature and
certificate validation.

Yes, but the IdP isn't validating the signature, it's creating it. And you
don't want the vendor doing X.509 anything, you want them pulling the key
out of the certificate you give them or from the metadata if by some
miracle they support metadata, and using that directly.

Right, and you definitely want the SP to support metadata (i.e.,
multilateral federation). That would be at the top of my "must have"
list, whereas encryption would be merely a "nice to have."

Tom

[Lohr, Donald]

Again, out of my ignorance.

This SP is not a InCommon metadata participating member.

Does my IdP have a "full endpoint-to-endpoint XML (assertion)
encryption" relationship with the InCommon SP's that we currently use,
without me doing much of anything on my end?

THX

Post by Cantor, Scott

Post by Lohr, Donald
Does the vendor support full endpoint-to-endpoint XML (assertion)
encryption via the use of a certificate model, compatible with the model
supported by Shibboleth?

We don't have our own model for this, it's simply required by SAML
implementations. All standard. Just for the record. When communicating
with vendors, it's usually best to not even mention Shibboleth at all
because it biases them with excuses about how we must be doing
non-standard things.

Post by Lohr, Donald
For starters, my Shibboleth 2.x knowledge is very limited, I'm a newby.
The above question is from a previous Shibboleth admin. I do not fully
understand this question we asked
the integrator.

SAML long ago deprecated the back-channel as an exchange path. Your
assertion travels from the IdP through the browser to the SP. The data
there is readable. XML Encryption makes it much harder to read if there's
malware in the client.

Post by Lohr, Donald
My question for the group, does Shibboleth 2.x support x509 signature and
certificate validation.

Yes, but the IdP isn't validating the signature, it's creating it. And you
don't want the vendor doing X.509 anything, you want them pulling the key
out of the certificate you give them or from the metadata if by some
miracle they support metadata, and using that directly. The workaround for
them not doing that is using long-lived certificates that are self-signed
to prevent mistakes.
-- Scott

--
D o n a l d L o h r

i n f o r m a t i o n s y s t e m s
j a m e s m a d i s o n u n i v e r s i t y

5 4 0 . 5 6 8 . 3 7 3 0

[Cantor, Scott]

Post by Lohr, Donald
Does my IdP have a "full endpoint-to-endpoint XML (assertion)
encryption" relationship with the InCommon SP's that we currently use,
without me doing much of anything on my end?

Yes.

-- Scott

[Tom Scavo]

Post by Lohr, Donald
Does my IdP have a "full endpoint-to-endpoint XML (assertion)
encryption" relationship with the InCommon SP's that we currently use,
without me doing much of anything on my end?

Scott quickly answered yes, so he may know something I don't, but the
only person that can answer the above question is you. Just because an
SP publishes its metadata in InCommon doesn't mean it meets the
requirements I listed earlier. Not at all.

Tom

[Lohr, Donald]

Without disclosing the SP (yet), what are some good questions I can ask
(over and above the one in my original email) to know we are not heading
down a path that may cause us to do something with our Shibboleth
service that we may regret or not have a secure handshake with this SP
or any SP, whether they are an InCommon metadata participating member or
not?

THX

Post by Tom Scavo

Post by Lohr, Donald
Does my IdP have a "full endpoint-to-endpoint XML (assertion)
encryption" relationship with the InCommon SP's that we currently use,
without me doing much of anything on my end?

Scott quickly answered yes, so he may know something I don't, but the
only person that can answer the above question is you. Just because an
SP publishes its metadata in InCommon doesn't mean it meets the
requirements I listed earlier. Not at all.
Tom

--
D o n a l d L o h r

i n f o r m a t i o n s y s t e m s
j a m e s m a d i s o n u n i v e r s i t y

5 4 0 . 5 6 8 . 3 7 3 0

[Tom Scavo]

Post by Lohr, Donald
Without disclosing the SP (yet), what are some good questions I can ask
(over and above the one in my original email) to know we are not heading
down a path that may cause us to do something with our Shibboleth
service that we may regret or not have a secure handshake with this SP
or any SP, whether they are an InCommon metadata participating member or
not?

I think we already covered the bases earlier in the thread. The first
question I ask of any potential SP partner is: What SAML software are
you using? If they say Shibboleth or simpleSAMLphp, I don't need to
ask much more since I know the capabilities of those two software
packages. Anything else is suspect because AFAIK no other software can
consume a federation's metadata aggregate, which is a nonstarter.

See: https://spaces.internet2.edu/x/R4HPAg

Tom

[Cantor, Scott]

Post by Tom Scavo

Post by Lohr, Donald
Does my IdP have a "full endpoint-to-endpoint XML (assertion)
encryption" relationship with the InCommon SP's that we currently use,
without me doing much of anything on my end?

Scott quickly answered yes, so he may know something I don't, but the
only person that can answer the above question is you. Just because an
SP publishes its metadata in InCommon doesn't mean it meets the
requirements I listed earlier. Not at all.

No, but the question I answered was not "does the SP fully support SAML
and all of the later work that Shibboleth builds on?", it was "are we
doing encryption end to end?".

The answer to the first question is simple because if the software isn't
Shibboleth, the answer to the first one is no.

-- Scott