OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp-interfaces] Groups - LeveraginSecurityStack-Strawman.pp tuploaded


Title: RE: [wsrp-interfaces] Groups - LeveraginSecurityStack-Strawman.pp tuploaded

Please see <ak> comment below.

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 22 July 2004 13:45
To: Andre Kramer
Cc: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Groups - LeveraginSecurityStack-Strawman.pp tuploaded





Hi Andre,

Andre Kramer <andre.kramer@eu.citrix.com> wrote on 07/22/2004 12:06:29 PM:

> Hi Richard,
> Everything the presentation suggests could be done but I don't
> really believe message level security is suited (i.e. meaning XML
> Encryption) to the use cases.

In that case we should revisit our use cases and rephrase them to our
requirements.

It seems elaborating much harder on our use cases and start to well-define
our needs would help us to enlighten our view on the broad term security.
Then we could come back and work ourselves through the securtiy solutions
jungle.

<ak> Agree, this would help but I was mainly pointing out that message level security may not be an immediate requirement. </ak>

As Mike said, we started with the simple intention to pass user identities.
We haven't talked about real federation, secure conversation, etc. yet, I
think.

> We need to protect more than the SOAP message. HTTP headers (cookies
> again) need protecting.

Could you elaborate about http header protection?
I guess you're think of http sessions here?

<ak>Yes, as this is the only header we use directly. At least we should protect that and point out the general issue of http protection.</ak>

The question is how far we want to step down towards the mixture of our web
service protocol and http.
The last discussions (cookie cleanup) indicated the sense that cookies are
considered "pulution" to the protocol?

<ak>I agree but don't we need to remove need for cookies first? Also, http resources require SSL so why go for message level security when we typically need SSL anyway? [I own this one!]</ak>

> Using Timestamps implies the producer needs
> to keep all messages in the valid time window (or remember just
> timestamps seen if they are used as a nonce)- too many for a busy
> producer.

agree, protecting against replay attacks can be hard to realize.

> Ultimately, we need to protect not just against simple
> replay attacks - conceptually we need to link one message to another
> and to the conversation context, so simple timestamps are not enough.

agreed, but I think we haven't been that far in our discussions yet.
My thought on this would be that:
a. Consumer signs up to the producer (by whatever means, a "business
secret" could be appropriate here, or using other means like certificates,
kerberos tickets, etc.).
b. Conusmer and producer set up a "conversation context", i.e. probably set
up some symmetric keys, and a conversation token
c. Consumer and producer use this secured context to exchange messages (and
protect them, i.e signing/encrypting)
d. Consumer and producer can destroy the conversational context

<ak> We can always fix problems e.g. by making registration handles secrets etc. But we should not re-invent connection security at the message level.

I was only aiming to show that message level security is not easy. </ak>

> For example, a consumer signing a username helps assert an identity
> but what prevents a producer re-playing that signed token to a
> second producer?

Well I think this depends on the set up. I guess we would need to add and
protect message originator, too.
This would mean signing the whole message or at least the headers, I guess.

<ak> Yes, the "To:" address and related SOAP headers.</ak>

Then the 2nd Producer would be able to a.) verify by whom the identity was
asserted (because the username token is signed) and b.) who the asserter is
(i.e. the sender of the assertion).
According to this information the 2nd producer could make its decisions.
If it trust the sender (1st Producer) and the consumer (identity provider)
then it could process the request.
This "trust chains" make this SSO possible.

> Worse, a fully signed register message could be
> used in such a spoof if it does not include any reference to the
> first (malicious) producer. Message level security can be tricky...

Yes, true. That's why I think the sender of a message needs to authenticate
itself, too.
But isn't that always the case if we try to solve real world SSO issues?
Again, I think we started with some "simple" and prio 1 ones.
I think use cases 8-11 try to deal with this?

<ak> Not sure what we end up protecting against if we do not address such basic trust issues though. </ak>

> SSL in more efficient than message level security and ensures
> conversation context security (message level does not). But is SSL
> (with client certs or HTTP basic authentication) enough?

Yes, SSL is more efficient today than XML enc/XML dsig. And secure
conversation is not there yet.
SSL seems not to be enough once we leave the point-to-point ground.
One example are intermediaries (like SOAP routers/workload balancers).
But some more obvious ones are the ones you mentioned above; producer
passing useridentiy to yet another producer or backend system.

> I think we also need a username/password for establishing wsrp
registrations.

Trust between these two could be seen as a "registration".
And I agree, there are two identities that we generally need to pass.
The first one is the identity of the Consumer, i.e. the actual sender of
the messages.
The second one is the user identity assertion (and probably an additional
role assertion if we want to have this, too)
While the first one secures the conversation between the consumer and can
be used to check whether a wsrp reg. handle is valid comming from a
particular sender, or make other similar decisions, the second one is
basically used to enable a SSO experience for the end-user (and probably do
authentication decision based on this id, too).

<ak> And we may have both end-user and admin identities/roles to consider. </ak>

> Here, it's an admin / producer account and not the end user "loggin
> in" and this principle may differ from the connection security
> context. This implies we do need WS Security to carry a
> username/password for registration (and Registration handles need to
> be secrets).

agreed. I think use cases 8-11 target for this. Perhaps we need to
fine-tune them.
We haven't been that far, yet and seem to go far beyond what Mike felt as
required in yesterday's call.

> While we could use a SAML assertion to assert admin
> identity and rights, it seems simpler to bootstrap a registration
> using a username/credential token. A producer could then
> (optionally) validate and record any SSL certificate presented by
> the consumer and use that to bootstrap trust.

Agreed, this could be one solution for that.
Onother option is, as I briefly mentioned that the producer could simply
act as a security token service.
Then we would have the following:
1. Consumer sends a "obtain token" request to the Producer (security token
service) using a username/PW token as you said it; for encryption either
SSL could be user or again XML encryption using the Producer's public key.
2. Producer authenticates the consumer (id/pw) and issues a token (could be
a X.509 certificate for example)
3. Consumer uses this token throughout the complete conversation as a proof
of access posession.

<ak> Other patterns are possible. E.g. a consumer could have an attribute authority that a producer could query by callback (e.g. for role information). I was concentrating on the minimal point-to-point federation. </ak>

> The need for support for roles has been raised. Like identity, these
> should be asserted e.g. using SAML attributes but here we start
> defining our own "protocol", as I don't think roles are a SAML
> defined concept (XACML?).

I'm not sure. I though the SAML folks are working on a profile covering
this.
I see two options here SAML attribute or a role profile as you both
mentioned.
We would need to explore it in detail.

<ak>yes, needs investigation.</ak>

> And we need to be able to cache a token in a session so as to avoid
> re-sending it. If it is a SAML statement it will be large. If it's a
> password then safer not send it twice ;-) This impacts our protocol
> and makes our protocol a "conversation" - which goes back to my
> first point on message level security.

Yes, caching might by an issue here.
As you state it right this would go back to conversation.
But we have to keep in mind that this would mean we had multiple
conversations (for each user) since they will have different roles
assigned.

<ak>Not sure I understand the need for multiple conversations as a consumer could just assert all roles a user has at a producer and multiplex many users over a single connection? </ak>

> Therefore, I think SAML could be the primary standard we use. This
> would mean userID can be asserted using a SAML assertion (Subbu's
> point) and (say) roles are extra attributes statements (or one extra
> canned assertion that wsrp 1.0 user categories can be mapped to
> security roles by a producer :-).

Right, I think there are multiple ways to assert userids. And there are
multiple solution for that.
Using the plain username token can be taken as an example (because it's
simple and well understood and has less overhead than a SAML assertion) in
the slides.
I did not want to explicitly propagate just the username token approach.
I coud easily think of other kinds of token, like XML token containing SAML
assertions, X.509 certificates in binary tokens or the could old plain and
simple userid token.

> SAML defines "profiles" for
> different use cases. Maybe we could develop a SAML profile for WSRP?

would need to dig into details here.

> Then WS Security (in SSL) is just the transport mechanism for the
assertion.
> Actually, WS Security really is just instructions for using
> SAML(draft) and other tokens, XML Sign, XML Enc with SOAP rather
> than new security mechanisms.
completly agree. And that was my point yesterday. It is a framework for
transporting security tokens, signing and encrypting messages (or parts of
these). Other standard will utilize this framework and provide solutions
based on this framework which solve the various security areas, like trust
relationships, identity ferderation, secure conversational context, etc.

> This simple use of security standards would not need to be policy
> driven but would need some SHOULDs / MUSTs on SAML assertion and
> some METADATA for roles (allowing a producer to list roles that the
> consumer can assert).

probably, we need to dig in deeper here.

> Finally, would people not also expect certificates as WS Security
> tokens or SAML assertion signing? Then we need to clarify if it is
> the consumer signing a token or if the token is signed by the user
> (i.e. sender-vouches or holder-of-key).

yes! I think we need to think about what the consumer is in our security
scenarios.
First, the identity provider (I'll leave it open for now who it is) needs
to sign the userid and/or role assertion since it is the issuer of the
"identity". We need to make sure that we understand what identity is.
Second the sender of our protocol message need to sign the messages (for
the use cases you described).
If we think carefully about the consumer then I could likely imagine the
consumer in two roles:
1. the consumer (typically a portal which is authenticating the users)
could be viewed as an identity provider. By issuing such a identity token
the consumer says: this is user X and I authenticated that user. Then other
can trust that consumer and use this assertion for their purposes.
2. the consumer can act as an intermediary. Here users could obtain their
identity token from yet another party (again an identity provider).
Here the consumer would trust the identity provider and allow the user to
access the portal. In interactions with producers they would simply forward
this asserted identity and say: I interact on this user's behalf and here
is its id. The producer in turn would need to trust the initiating identity
provide.

I think this is a typical scenario for SSO in todays systems. First an
identity provider issues some kind of token, then services obtain these
token and forward them to an authentication server (could be the id
provider) and ask them to validate that token. Once the validation is
complete they grant access-.

<ak>We seem to be touching on federation issues much more than simple use of WS Security.</ak>

> Then SAML with WS Security
> starts to look quite complex.

Yes, unfortunatly I real secure solution is always complex, I guess.

> Possibly we can get away with some SHOULD be signed in the short term?

agreed, as Mike pointed out in some intranet scenarios we have trust by
"social connection", i.e. I trust the servers in my intranet.
Here we are left with just id propagation?

<ak> My "Possibly" sentence got disconnected from the proceeding paragraph. I was only speculating about limiting the WS Security / SAML complexity.</ak>

> The above are not a firm proposal or recommendations, just my input
> to the discussion. And I'm not discouraging using message level
> security when needed for traversing SOAP intermediaries.
> Regards,
> Andre `

Thanks Andre.
I think this is are very valueable comments and I appreciate them.
I hope this helps us to open a vital discussion.
Your comments show to me (and I agree with them) that security is not just
simple "user string" passing but is far more complex.
We started with some simple use cases to solve some of our basic
requirements. But when it comes to true security and SSO scenarios (trust,
encryption, signing, attack protection, federating ids across securtiy
domains, integrating various systems) things become far more complex and
are not easy to solve.
Perhaps we can't provide a full flegded solution yet, but this proves to me
that we might want to take a staged approach which easily allows it to be
extended towards a complete solution. And there is hope that these
requirements are so common with other web services that others will provide
a solution to these.

<ak>The Web security technologies are designed to be composable / extensible but one still needs to do a lot of work for solutions! </ak>


Richard



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]