Web Service End-to-End Security

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Web Service End-to-End Security

Jonathan Tellier
Hello,

I've got a Shibboleth deployment protecting Web services and I
authenticate to them by using the SAML ECP Profile. The authentication
and authorization process works well, but now, I would like to add
end-to-end message security, following the idea of what it's possible
to achieve with WS-Security. I am using SSL, but that only provides
point-to-point security. I would ideally want my message to be
encrypted by my Web service client and decrypted by my Web service
provider.

I know that Shibboleth is not really designed to solve that kind of
problem, but what would be the best way to work out a solution by
using it? Would my best bet be to secure my Web services using
WS-Security and authenticate to it using the SAML tokens emitted by
the IdP? Would those token be suitable for this kind of use i.e.,
would they be able to convey XML-Encryption information?

Note that I'm not really experienced in all things related to WS-*, so
maybe I'm looking at this problem backwards.

Thanks,
Jonathan
Reply | Threaded
Open this post in threaded view
|

RE: Web Service End-to-End Security

Cantor, Scott E.
> I've got a Shibboleth deployment protecting Web services and I
> authenticate to them by using the SAML ECP Profile. The authentication
> and authorization process works well, but now, I would like to add
> end-to-end message security, following the idea of what it's possible
> to achieve with WS-Security.

It would be better to describe what you want without referring to
WS-Security, because that just introduces overwhelming vagueness.
 
> I am using SSL, but that only provides
> point-to-point security. I would ideally want my message to be
> encrypted by my Web service client and decrypted by my Web service
> provider.

You could do that at the application layer if you don't need any headers
encrypted.

> I know that Shibboleth is not really designed to solve that kind of
> problem, but what would be the best way to work out a solution by
> using it?

I don't think there is a best way, really, just a lot of painful ones. We
made progress after years of nothing by dumping message security and
focusing on a problem we could solve.

> Would my best bet be to secure my Web services using
> WS-Security and authenticate to it using the SAML tokens emitted by
> the IdP?

The IdP doesn't generally issue tokens that are suitable, you'd have to
develop a profile handler to do that.

> Would those token be suitable for this kind of use i.e.,
> would they be able to convey XML-Encryption information?

SAML assertions are generally used for authentication, not encryption.
Encryption relies on the peer's key, not your own. WS-Security includes
guidance on encrypting SOAP messages, but I don't think it has much to do
with the security token stuff apart from maybe some of the weirder stuff
involving derived keys. The "simple" way of doing encryption doesn't rely on
key derivation, just generating a bulk key and encrypting it to the peer.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Web Service End-to-End Security

Jonathan Tellier
> It would be better to describe what you want without referring to
> WS-Security, because that just introduces overwhelming vagueness.

OK, here's a simplified, technology agnostic sample use case that
could give you an idea of what:

An ECP-capable client is used to access a (Java) Web service provider
protected by an SP. After the token exchange and authentication dance,
the client is able to query the Web service provider by sending it
SOAP messages.

However, all the messages that are sent from the client to the Web
service provider are sent "in the clear". I used quotes here because
SSL is used, but I would need end-to-end security. The idea is that
multiple instances of the Web service provider will be deployed in
domains that I don't control, so I have no idea where the SSL
connection will end. For that reason, I would like the messages to be
encrypted and decrypted by the endpoints (queries encrypted by the
client and decrypted by the Web service provider and responses
encrypted by the Web service provider and decrypted by the client).

> The IdP doesn't generally issue tokens that are suitable, you'd have to
> develop a profile handler to do that.

Ideally, I'd like to use already existing solutions and stay away from
custom modifications. I have looked at the Wiki, but I'm not sure I
understood what a custom profile handler would imply. I guess the SP
would have to be modified to handle this custom profile, right?

> The "simple" way of doing encryption doesn't rely on
> key derivation, just generating a bulk key and encrypting it to the peer.

I guess that this approach would work and it would require for every
clients and Web service providers to have its own key pair. I'm just
brainstorming here, but could the client's public key be contained in
the authentication token emitted by the IdP to the SP?

Thanks,
Jonathan
Reply | Threaded
Open this post in threaded view
|

Re: Web Service End-to-End Security

Jim Fox

The IdP will optionally encrypt assertions.

Jim


On Thu, 16 Sep 2010, Jonathan Tellier wrote:

> Date: Thu, 16 Sep 2010 14:34:49 -0700
> From: Jonathan Tellier <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Subject: Re: [Shib-Users] Web Service End-to-End Security
>
>> It would be better to describe what you want without referring to
>> WS-Security, because that just introduces overwhelming vagueness.
>
> OK, here's a simplified, technology agnostic sample use case that
> could give you an idea of what:
>
> An ECP-capable client is used to access a (Java) Web service provider
> protected by an SP. After the token exchange and authentication dance,
> the client is able to query the Web service provider by sending it
> SOAP messages.
>
> However, all the messages that are sent from the client to the Web
> service provider are sent "in the clear". I used quotes here because
> SSL is used, but I would need end-to-end security. The idea is that
> multiple instances of the Web service provider will be deployed in
> domains that I don't control, so I have no idea where the SSL
> connection will end. For that reason, I would like the messages to be
> encrypted and decrypted by the endpoints (queries encrypted by the
> client and decrypted by the Web service provider and responses
> encrypted by the Web service provider and decrypted by the client).
>
>> The IdP doesn't generally issue tokens that are suitable, you'd have to
>> develop a profile handler to do that.
>
> Ideally, I'd like to use already existing solutions and stay away from
> custom modifications. I have looked at the Wiki, but I'm not sure I
> understood what a custom profile handler would imply. I guess the SP
> would have to be modified to handle this custom profile, right?
>
>> The "simple" way of doing encryption doesn't rely on
>> key derivation, just generating a bulk key and encrypting it to the peer.
>
> I guess that this approach would work and it would require for every
> clients and Web service providers to have its own key pair. I'm just
> brainstorming here, but could the client's public key be contained in
> the authentication token emitted by the IdP to the SP?
>
> Thanks,
> Jonathan
>
Reply | Threaded
Open this post in threaded view
|

Re: Web Service End-to-End Security

Jonathan Tellier
> The IdP will optionally encrypt assertions.

Yes, I know that, but what I would like to encrypt is the messages
that are exchanged *after*  the authentication phase. I would like to
secure the queries and response that are exchanged between the Web
service client and the Web service provider, after the Web service
client has authenticated with the SP.

Jonathan
Reply | Threaded
Open this post in threaded view
|

RE: Web Service End-to-End Security

Cantor, Scott E.
In reply to this post by Jonathan Tellier
> However, all the messages that are sent from the client to the Web
> service provider are sent "in the clear".

Alluding to what I said in the previous message, you haven't indicated
whether what you care about is the body of the SOAP message, or the SOAP
message itself. If it's the body, then ultimately whether that's in the
clear or not is not necessarily determined only by the middleware.

I'm not saying it's the best solution to make the application deal with the
encryption, but SOAP message security is incredibly hard to deal with, and
XML encryption per se actually isn't that hard if you have the peer's key.

> Ideally, I'd like to use already existing solutions and stay away from
> custom modifications.

What you want is not possible at all with the existing software. We
deliberately ignored message level security as too complicated and
non-interoperable. When we finally tackled the "service" problem, we did it
with an HTTP session model. The fundamental idea with that on the server
side was that the SP could slide in unmodified and services would act like
any other resources. That's totally different from the SOAP security model.

> I have looked at the Wiki, but I'm not sure I
> understood what a custom profile handler would imply. I guess the SP
> would have to be modified to handle this custom profile, right?

The SP isn't really involved. The SP is about HTTP and setting up sessions
between network endpoints to protect HTTP resources. There's nothing the SP
does that is relevant to protecting SOAP messages that aren't internal to
its SAML processing. It uses code that has relevance to some of that problem
space, particularly evaluating SAML assertions, but there's no direct
equivalence at the level of the "product". The SP deals in SAML requests and
responses. The assertions it deals with are part of the payload of that
protocol, they aren't part of some other application protocol.

> I guess that this approach would work and it would require for every
> clients and Web service providers to have its own key pair. I'm just
> brainstorming here, but could the client's public key be contained in
> the authentication token emitted by the IdP to the SP?

That would be a holder of key assertion and the IdP has no code for that
yet. But more importantly, the assertions the IdP issues today are not for
message security. They're short lived assertions carried in SAML responses
that are used to create sessions based on other technologies like cookies.
They're not like Kerberos tickets or message tokens that last a few hours or
whatever one might expect.
 
Ignoring that problem, you basically would need something like that to
communicate a key to the server that would be used to encrypt its responses
back to the client. That still leaves the client needing to know the
server's key, and it's not obvious that the IdP even plays a role there if
it's not somehow involved in authenticating the server to the client.

I guess my advice would be that you seem to want to use the WS-* security
model here, so you probably need to look at code that supports that.
Possibly WS-SecureConversation is something you would need. I think its
focus is on turning tokens into keys, which is more or less what you're
trying to do. It's well beyond my crypto pay grade, I'm afraid.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Web Service End-to-End Security

Jonathan Tellier
> Alluding to what I said in the previous message, you haven't indicated
> whether what you care about is the body of the SOAP message, or the SOAP
> message itself. If it's the body, then ultimately whether that's in the
> clear or not is not necessarily determined only by the middleware.

Just to be sure that I understand correctly: if I would like to
encrypt both the headers and body, I *could* resort to a middleware
solution. However, Shibboleth is not a solution that could do it in
the current state of things. Am I right?

Now, I mostly care about the body, but if an appropriate solution
happens to have the side effect of encrypting the headers too, I
wouldn't mind.

> The SP isn't really involved. The SP is about HTTP and setting up sessions
> between network endpoints to protect HTTP resources. There's nothing the SP
> does that is relevant to protecting SOAP messages that aren't internal to
> its SAML processing. It uses code that has relevance to some of that problem
> space, particularly evaluating SAML assertions, but there's no direct
> equivalence at the level of the "product". The SP deals in SAML requests and
> responses. The assertions it deals with are part of the payload of that
> protocol, they aren't part of some other application protocol.

I think that I don't really understand what profile handlers are for
then... If I take the ECP profile as an example, the SP has to include
additional logic to handle the messages related to this profile. But
maybe my case is different because the information conveyed in
messages sent using my custom profile would only by useful to the Web
service, not the SP? This new profile would be used to transfer keys
that would be useful only to the endpoint, not the SP, right?

> That would be a holder of key assertion and the IdP has no code for that
> yet. But more importantly, the assertions the IdP issues today are not for
> message security. They're short lived assertions carried in SAML responses
> that are used to create sessions based on other technologies like cookies.
> They're not like Kerberos tickets or message tokens that last a few hours or
> whatever one might expect.

What would prevent a SAML assertion to be valid for a few hours? They
might not be intended to be used that way, but if the information it
contains stays valid for a log period of time, why can't the assertion
stay valid for that same amount of time? Is that "issue" related to
SAML itself or its Shibboleth implementation? I've skimmed over the
SAML spec, looking for a reference to that kind of statement, but
could not find a place saying that the assertions have to be
short-lived (Don't take this as a challenge to what you're saying.
Your name is on that spec, so I reckon you know that stuff better than
I do. I'm just trying to understand).

> Ignoring that problem, you basically would need something like that to
> communicate a key to the server that would be used to encrypt its responses
> back to the client. That still leaves the client needing to know the
> server's key, and it's not obvious that the IdP even plays a role there if
> it's not somehow involved in authenticating the server to the client.

You're right, I've overlooked that part. Since the IdP does not
authenticate the endpoint to the client, I need another way for the
server to send its key to the client...

> I guess my advice would be that you seem to want to use the WS-* security
> model here, so you probably need to look at code that supports that.
> Possibly WS-SecureConversation is something you would need.

Indeed, a review of this specifications seem to indicate that it would
be suitable for what I'm trying to achieve. However, even though it
looks like it can be used standalone, it is closely tied to WS-Trust.
I'll have to look more closely into it. Thanks for the pointer.

I also think that Information Cards could help me solve my problem.
From what I've understood though, its support within Shibboleth is
pretty limited.

Jonathan
Reply | Threaded
Open this post in threaded view
|

RE: Web Service End-to-End Security

Cantor, Scott E.
> Just to be sure that I understand correctly: if I would like to
> encrypt both the headers and body, I *could* resort to a middleware
> solution. However, Shibboleth is not a solution that could do it in
> the current state of things. Am I right?

Yes, Shibboleth doesn't have any support for trying to protect application
content, we leave that to TLS.

> Now, I mostly care about the body, but if an appropriate solution
> happens to have the side effect of encrypting the headers too, I
> wouldn't mind.

And I was making the point that given knowledge of the public key, the code
to encrypt/decrypt XML in the body under that key is not terribly complex.

> I think that I don't really understand what profile handlers are for
> then... If I take the ECP profile as an example, the SP has to include
> additional logic to handle the messages related to this profile. But
> maybe my case is different because the information conveyed in
> messages sent using my custom profile would only by useful to the Web
> service, not the SP? This new profile would be used to transfer keys
> that would be useful only to the endpoint, not the SP, right?

Yes. Your application protocol is your own. The SP's "application protocol"
is SAML (or WS-Federation, or whatever it happens to implement support for),
and the end result is a session with the client (generally via cookie) for
authenticating HTTP requests. That's all the SP does. Anything else it does
would be in a supporting role for giving applications things that help them
do work related to interacting the IdP.
 
> What would prevent a SAML assertion to be valid for a few hours? They
> might not be intended to be used that way, but if the information it
> contains stays valid for a log period of time, why can't the assertion
> stay valid for that same amount of time?

Because they're bearer tokens, and long lived bearer tokens are a security
risk. They can be long lived, they just can't be used outside a very short
window unless they're bound to a key.

> Is that "issue" related to
> SAML itself or its Shibboleth implementation? I've skimmed over the
> SAML spec, looking for a reference to that kind of statement, but
> could not find a place saying that the assertions have to be
> short-lived (Don't take this as a challenge to what you're saying.
> Your name is on that spec, so I reckon you know that stuff better than
> I do. I'm just trying to understand).

Check the Browser SSO profile. There's a difference between assertion
lifetime and confirmation lifetime.

> I also think that Information Cards could help me solve my problem.

I don't think so. They are essentially unused in an "active client"
capacity, so there's not much precedence, but in general the IMI spec is
about authentication, not confidentiality. The passive version used with
browsers is definitely not applicable, and the active stuff is just about
acquiring tokens to attach to messages. I don't think it covers what you
would need, but would be happy to be shown otherwise.

> From what I've understood though, its support within Shibboleth is
> pretty limited.

There's alpha code, and the work is basically terminated unless people start
adopting Infocard. We're discussing how to reflect this in the roadmap.

-- Scott