[Shib-Users] Moving the back channel on the IdP from port 8443 to 443: caveats, pitfalls?
Kaspar Brand
> On Jan 14, 2011, at 8:55 PM, "Joshua Brodie" <josb...@gmail.com> wrote:
>> > What is port 8443 for?
> Anything using the SAML SOAP binding.
>
>> > I do not see any apache log entries today on port 8443 - Is port 8443 where the SP call to get attributes on an account (after authentication)?
> Primarily.
>
>> > Or is port 8443 only used for SAML1?
> Not exclusively, but mostly.
(Co)incidentally, I have been looking at port 8443 in the past
few days as well... at SWITCH, we're actually discussing whether we
could/should change the recommended IdP configuration in our deployment
guides, and switch from port 8443 to 443 for back channel communication.
This would considerably simplify the overall IdP configuration and
deployment (no listener required on 8443 any more).
After having played with it - in a Shib-only environment -, it seems
that the required changes would be "surprisingly simple" - that's at
least the reaction I got from some of my SWITCH buddies :-) ... but
before going further, we would be interested in hearing others' opinions.
Basic assumptions:
- We're looking at the IdP 2.2 or later, in the first place.
Also, it's primarily about changing the default setup for future
installations, not about modifying existing deployments.
- Hopefully, many of the SPs are now doing SAML2 - which makes the
need for back channel communication less likely. Still, we want to
support older Shib SPs, too, but consider it acceptable if the
configs of these SPs have to (minimally) adapted.
And here's what I did in my experiments:
- On the SP: made sure that it signs its (attribute and artifact
resolution) queries. For 2.x, this is achieved by adding
signing="back" (or "true") to the ApplicationDefaults element,
for 1.3 it's done by adding signRequest="true" to the
CredentialUse element.
- On the IdP: made sure that there is no listener on port 8443
(to guarantee that all requests will come in to the IdP on 443 only).
- In the metadata: changed the AttributeService and
ArtifactResolutionService locations of the IdP to point to port 443.
So far, my test were successful with both the 2.4 SP and some 1.3 legacy
stuff (SP 1.3f with OpenSAML 1.1b, Xerces-C 2.7.1 and XML-Security-C
1.2.1 - yes, hopefully outdated and quite insecure, I guess). I have
successfully tested both attribute and artifact resolution, with SAML1
and SAML2.
What these changes essentially boil down to is: making TLS client auth
in the back channel obsolete, and switching to message-level security
for requests directed at the IdP. What's quite nice with this solution,
too, is that the default security policies for the IdP already take care
of everything, so no changes are required in relying-party.xml
(the MandatoryMessageAuthentication rule will correctly enforce that
the message is authenticated either at the transport or at the message
level).
Which finally brings me to some questions which came up in our discussions:
- Are there general caveats when going this route? Pitfalls we
should be aware of? Is request signing on the SP going to "kill"
performance?
- Are we likely to run into problems with certain older SP gear...?
(bugs in specific version of XML-Security-C etc.?)
- Interoperability with non-Shib implementations: what are the chances
of running into troubles there?
... or is this whole plan just a bad idea because a) it's flawed anyway,
and b) because ${your_argument_here}? Looking forward to feedback from
the list - thanks.
Kaspar
Chad La Joie
On 1/17/11 8:23 AM, Kaspar Brand wrote:
> - On the IdP: made sure that there is no listener on port 8443
> (to guarantee that all requests will come in to the IdP on 443 only).
This doesn't guarentee that, it just means that if a request is sent to
8443 it'll fail with a connection timeout.
> What these changes essentially boil down to is: making TLS client auth
> in the back channel obsolete, and switching to message-level security
> for requests directed at the IdP. What's quite nice with this solution,
> too, is that the default security policies for the IdP already take care
> of everything, so no changes are required in relying-party.xml
> (the MandatoryMessageAuthentication rule will correctly enforce that
> the message is authenticated either at the transport or at the message
> level).
Yeah, pretty sure those policies have been there since 2.0.0. I had
always been the case with 2.X that we wanted to allow people to run
using message security on the front channel.
> - Are there general caveats when going this route? Pitfalls we
> should be aware of? Is request signing on the SP going to "kill"
> performance?
One issue is that you may not be able to do client-cert authentication
of users unless you shunt them off to a different host (which I think is
actually what you guys do).
Performance wise, you'd kill the IdP before you killed the SP with
crypto operations. While the JVM crypto ops have been getting a lot
better they're still slower than openssl.
> - Interoperability with non-Shib implementations: what are the chances
> of running into troubles there?
No idea. If they can sign requests then you're fine.
> ... or is this whole plan just a bad idea because a) it's flawed anyway,
> and b) because ${your_argument_here}? Looking forward to feedback from
> the list - thanks.
No, I've certainly recommended it before to people (to SWITCH in fact a
few years ago). I think it makes things cleaner, as you noted, and when
coupled with things like channel bindings (which we don't yet support)
makes the message more secure overall.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Velpi
>> should be aware of? Is request signing on the SP going to "kill"
>> performance?
>
> One issue is that you may not be able to do client-cert authentication
> of users unless you shunt them off to a different host (which I think is
> actually what you guys do).
You could configure optional cert-request for 443. But that is annoying
for users that actually do have a personal certificate too.
I did hear recently that an Apache httpd front might be able to do cert
request *per-location*. Never tried it myself though and it sounds
conceptually impossible to me.
--
/---------------------------------------------
| Jan "Velpi" Van der Velpen
| Ve...@industria.be || +32 (0) 498 61 24 89
\---------------------------------------------
Chad La Joie
particularly bad behavior when it comes to this.
As far as per-location requirements this would, I believe, requires the
use of TLS renegotiation which, as far I know, is still broken.
On 1/17/11 8:46 AM, Velpi wrote:
>>> - Are there general caveats when going this route? Pitfalls we
>>> should be aware of? Is request signing on the SP going to "kill"
>>> performance?
>>
>> One issue is that you may not be able to do client-cert authentication
>> of users unless you shunt them off to a different host (which I think is
>> actually what you guys do).
>
> You could configure optional cert-request for 443. But that is annoying
> for users that actually do have a personal certificate too.
> I did hear recently that an Apache httpd front might be able to do cert
> request *per-location*. Never tried it myself though and it sounds
> conceptually impossible to me.
>
--
Rod Widdowson
Chad La Joie
port. There is only the front-channel/browser cert.
--
Rod Widdowson
Cantor, Scott E.
> (bugs in specific version of XML-Security-C etc.?)
I really don't recall at this point, you'd have to test them. There are
certainly bugs in older libraries that might affect signing interop.
>- Interoperability with non-Shib implementations: what are the chances
> of running into troubles there?
The rule of thumb is that the vendors tend to favor signing over TLS.
>... or is this whole plan just a bad idea because a) it's flawed anyway,
>and b) because ${your_argument_here}? Looking forward to feedback from
>the list - thanks.
My biggest problem with it is that it promotes the use of shorter-lived
commercial certificates into the SAML domain, which causes hassles IMHO
that aren't worth the benefit of saving a port. Key management is to
atrocious with the commercial products that having to change certs every
year or two years wouldn't appeal to me.
-- Scott
Kaspar Brand
> How are you switching between the browser facing certificates and the
> shibboleth facing certificates?
Good point - thanks for raising this. As Chad already noted, there's
only one cert we would use for TLS in this case. But it's worth
mentioning that the SP either needs to be configured with PKIX
validation and the necessary trust anchors (which was the case in my
test setups), or that the "browser facing" cert needs to be added to the
metadata (for use by the ExplicitKey trust engine).
Kaspar
Chad La Joie
cert for signing. It may still use the self-generated one and, if it
does so, that is the cert that would need to be in metadata.
--
Kaspar Brand
> My biggest problem with it is that it promotes the use of shorter-lived
> commercial certificates into the SAML domain, which causes hassles IMHO
> that aren't worth the benefit of saving a port. Key management is to
> atrocious with the commercial products that having to change certs every
> year or two years wouldn't appeal to me.
For the SWITCHaai federation, we are also limiting the lifetime of
self-signed certs to three years (because keeping the same key pair for
10 years wouldn't be good practice either), so key renewal is something
which IdP admins will run into anyway. The current plan would be to keep
the self-signed cert for (message) signing, and use the browser-facing
cert for TLS.
Kaspar
Kaspar Brand
> Note that there is no requirement that the IdP use the front-channel
> cert for signing. It may still use the self-generated one and, if it
> does so, that is the cert that would need to be in metadata.
Yes, exactly. That's what I'm doing now in my setup (I continue to use
the self-signed cert for message signing).
Kaspar
Kaspar Brand
> Annoyance aside that doesn't work in every browser. If I recall IE has
> particularly bad behavior when it comes to this.
>
> As far as per-location requirements this would, I believe, requires the
> use of TLS renegotiation which, as far I know, is still broken.
This specific aspect is somewhat off-topic, but for the sake of
completeness: per-location TLS client authentication is doable with
Apache's mod_ssl, and if you use reasonably recent versions of OpenSSL,
it can also be done securely (à la RFC 5746).
Moving the back channel to port 443 doesn't change anything with the
current situation on the front channel, however, so that's not of real
concern to us (and yes, we're currently using a separate VirtualHost
with Apache for the client auth stuff, but that's a different story,
really).
Kaspar
P.S. And by the way: thanks to all who contributed to the thread so far!
Chad La Joie
On 1/18/11 8:20 AM, Kaspar Brand wrote:
> On 17.01.11 14:56, Chad La Joie wrote:
>> Annoyance aside that doesn't work in every browser. If I recall IE has
>> particularly bad behavior when it comes to this.
>>
>> As far as per-location requirements this would, I believe, requires the
>> use of TLS renegotiation which, as far I know, is still broken.
>
> This specific aspect is somewhat off-topic, but for the sake of
> completeness: per-location TLS client authentication is doable with
> Apache's mod_ssl, and if you use reasonably recent versions of OpenSSL,
> it can also be done securely (à la RFC 5746).
Does that RFC require client-side changes as well? If so, then maybe
it'll be okay to rely on it... in about 5-10 years. Before then most
browsers are just going to be doing the same bad behavior they have today.
Kaspar Brand
Yes, both the client and the server must be upgraded.
This time, browsers/clients have been comparably quick, however - one of
the last movers was actually Microsoft, with MS10-049 last October [1].
One of the guys who originally discovered this (protocol) issue is also
maintaining a list of updated implementations at
http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches.
So, provided that the system is up-to-date wrt security patches, secure
renegotiation will even work with MSIE6 on Windows XP :-)
Kaspar
[1] http://www.microsoft.com/technet/security/bulletin/ms10-049.mspx
Kaspar Brand
> This time, browsers/clients have been comparably quick, however - one of
> the last movers was actually Microsoft, with MS10-049 last October [1].
Ermm, that should have read "last August", to be precise.
Kaspar
Kaspar Brand
>> of running into troubles there?
>
> The rule of thumb is that the vendors tend to favor signing over TLS.
>
>> ... or is this whole plan just a bad idea because a) it's flawed anyway,
>> and b) because ${your_argument_here}? Looking forward to feedback from
>> the list - thanks.
>
> My biggest problem with it is that it promotes the use of shorter-lived
> commercial certificates into the SAML domain, which causes hassles IMHO
> that aren't worth the benefit of saving a port. Key management is to
> atrocious with the commercial products that having to change certs every
> year or two years wouldn't appeal to me.
One issue showed up with my tests in January, and meanwhile I finally
managed to figure out a way to address this. Moving the back channel to
443 also means that the SP's SOAP client may encounter a TLS cert which
it can't validate, possibly (assuming that we drop all KeyAuthority
elements [PKIX trust anchors] from our metadata at some point in the
future). Fortunately enough, this can be addressed by two configuration
changes:
- on the SP: add requireTransportAuth="false" [1] to the
ApplicationDefaults element (or ApplicationOverride/RelyingParty) -
this basically enables message-level security for the back channel
- on the IdP: for the SAML2AttributeQueryProfile, set
signAssertions="always" - otherwise the SP can't verify the
attribute statements (I also tested attribute pull with SAML 2,
even though push is the default, I know)
We can add these specific settings to our deployment guides, of course,
but the question is: would changing these defaults also make sense for
the standard SP/IdP releases (by changing the code and/or config)? Are
there strong arguments against?
For the IdP, I'm aware of SC-116 [2], which implemented the following
defaults for SAML 2:
> saml 2 sso: response never, assertion always
> saml 2 attribute query: response conditional, assertion never
> saml 2 artifact resolution: response never, assertion always
but I couldn't find a specific reason why signAssertions defaults to
"never" for attribute query responses (vs. "always" for the other two).
Kaspar
[2] "By default, always sign SAML Response for SAML 1.1 SSO"
https://bugs.internet2.edu/jira/browse/SC-116
Cantor, Scott E.
> signAssertions="always" - otherwise the SP can't verify the
> attribute statements (I also tested attribute pull with SAML 2,
> even though push is the default, I know)
I assume you mean the SAML 1 profile, since most IdPs shouldn¹t even be
offering the 2.0 version. In turn, you can't do message level encryption
with SAML 1, thus most deployers probably would insist on TLS being in
place rather than not.
>We can add these specific settings to our deployment guides, of course,
>but the question is: would changing these defaults also make sense for
>the standard SP/IdP releases (by changing the code and/or config)? Are
>there strong arguments against?
Well, the old IdP didn't support message level security well, so there's a
compatibility aspect to things, but it doesn't break anything in the SP
except that the "require confidentiality" test is based on TLS being in
place and it doesn't account for a case where it's TLS but without
authentication.
>but I couldn't find a specific reason why signAssertions defaults to
>"never" for attribute query responses (vs. "always" for the other two).
Because the assertion has no requirement to be stand alone or forwardable.
I'm still missing the underlying advantage here. I don't see why you'd
ever want to take on the complexity of doing SOAP against a browser port
unless you have to (namely inbound to an SP). IdPs can trivially handle it
on a separate port and tons of things get simpler, cleaner, and faster.
-- Scott
Kaspar Brand
>> - on the IdP: for the SAML2AttributeQueryProfile, set
>> signAssertions="always" - otherwise the SP can't verify the
>> attribute statements (I also tested attribute pull with SAML 2,
>> even though push is the default, I know)
>
> I assume you mean the SAML 1 profile, since most IdPs shouldn¹t even be
> offering the 2.0 version. In turn, you can't do message level encryption
> with SAML 1, thus most deployers probably would insist on TLS being in
> place rather than not.
No, I'm talking about SAML 2. Attribute queries are definitely less
frequent there, but we need to support them as well (e.g. for our VO
platform, which uses it for attribute aggregation, from what I understand).
When instructing the SP to encrypt the attribute queries
(encryption="back"), I think I actually found an issue with the IdP: it
can't handle EncryptedID elements (even though they are encrypted with
the proper key) and fails with "Unable to resolve principal, attribute
request ID and subject name identifier may not be null". Will double
check and file a bug in JIRA, if needed.
> Well, the old IdP didn't support message level security well, so there's a
> compatibility aspect to things, but it doesn't break anything in the SP
> except that the "require confidentiality" test is based on TLS being in
> place and it doesn't account for a case where it's TLS but without
> authentication.
Hopefully all IdPs in our federation are 2.x somewhen this year, so
that's of less concern. requireTransportAuth="false" and
encryption="back" would also prevent the SP from leaking any information
in a query to a rogue IdP.
>> but I couldn't find a specific reason why signAssertions defaults to
>> "never" for attribute query responses (vs. "always" for the other two).
>
> Because the assertion has no requirement to be stand alone or forwardable.
I'm mainly wondering why it is different when using artifacts - in this
case, I basically get the same assertion (the main difference being that
the attribute query response doesn't include the AuthnStatement), but
artifact responses are always signed.
> I'm still missing the underlying advantage here. I don't see why you'd
> ever want to take on the complexity of doing SOAP against a browser port
> unless you have to (namely inbound to an SP). IdPs can trivially handle it
> on a separate port and tons of things get simpler, cleaner, and faster.
According to our experience, maintaining separate TLS endpoints (on
separate ports and/or virtual interfaces) isn't really trivial. Also,
the way TLS client auth is handled in the Apache+Tomcat case isn't
particularly elegant, to put it mildly. (It's not really end-to-end
security, and is only "acceptable" if you run Apache and Tomcat on the
same system).
Kaspar
Cantor, Scott E.
>(encryption="back"), I think I actually found an issue with the IdP: it
>can't handle EncryptedID elements (even though they are encrypted with
>the proper key) and fails with "Unable to resolve principal, attribute
>request ID and subject name identifier may not be null". Will double
>check and file a bug in JIRA, if needed.
It's a request for enhancement. There's not meant to be any support for
inbound encryption in the IdP right now.
>I'm mainly wondering why it is different when using artifacts - in this
>case, I basically get the same assertion (the main difference being that
>the attribute query response doesn't include the AuthnStatement), but
>artifact responses are always signed.
They aren't signed, the assertion is. Artifact usage is an authentication
profile, and the resulting assertion is signed so that use with delegation
or other flows in which the original assertion has to be usable as a token
can work. In general, SAML 2 defaults are to sign the assertion during SSO.
Attribute queries are a different type of usage, and since the
authentication there is being handled by TLS normally, we don't bother to
sign at all unless we have to, and if we do, it's at the protocol layer.
>According to our experience, maintaining separate TLS endpoints (on
>separate ports and/or virtual interfaces) isn't really trivial.
Well, all I can say is that it's been much easier than the alternatives.
> Also,
>the way TLS client auth is handled in the Apache+Tomcat case isn't
>particularly elegant, to put it mildly. (It's not really end-to-end
>security, and is only "acceptable" if you run Apache and Tomcat on the
>same system).
Yes, but that's the normal model (if you even run Apache at this point,
which isn't really needed in most cases).
All I can say is, changing the security model of the system at this point
is not a likely candidate for a non-major upgrade. Perhaps for 3.0.
-- Scott
Kaspar Brand
>> When instructing the SP to encrypt the attribute queries
>> (encryption="back"), I think I actually found an issue with the IdP: it
>> can't handle EncryptedID elements (even though they are encrypted with
>> the proper key) and fails with "Unable to resolve principal, attribute
>> request ID and subject name identifier may not be null". Will double
>> check and file a bug in JIRA, if needed.
>
> It's a request for enhancement. There's not meant to be any support for
> inbound encryption in the IdP right now.
Ok, I'll file it as an improvement-type issue in JIRA.
> All I can say is, changing the security model of the system at this point
> is not a likely candidate for a non-major upgrade. Perhaps for 3.0.
I understand. Since our use case can be currently be addressed by
adapting the configuration, I'm fine with this solution right now. My
primary hope for 3.0, then, is that it will also be able to handle
queries encrypted at the message level.
Kaspar
Kaspar Brand
> On 25.03.11 11:08, Cantor, Scott E. wrote:
>> It's a request for enhancement. There's not meant to be any support for
>> inbound encryption in the IdP right now.
>
> Ok, I'll file it as an improvement-type issue in JIRA.
Meanwhile I realized that there's already an item for this:
https://bugs.internet2.edu/jira/browse/SIDPT-10
"Support receiving the <EncryptedID> element"
> I understand. Since our use case can be currently be addressed by
> adapting the configuration, I'm fine with this solution right now. My
> primary hope for 3.0, then, is that it will also be able to handle
> queries encrypted at the message level.
For the records: I filed https://bugs.internet2.edu/jira/browse/SIDPT-55
and https://bugs.internet2.edu/jira/browse/SSPCPP-356 to consider
changing the defaults for the 3.0 release(s).
Kaspar