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.ppt uploaded


Title: RE: [wsrp-interfaces] Groups - LeveraginSecurityStack-Strawman.ppt uploaded

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.

We need to protect more than the SOAP message. HTTP headers (cookies again) need protecting. 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. 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.

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? 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...

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?

I think we also need a username/password for establishing wsrp registrations.
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). 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.

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?).

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.

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 :-). SAML defines "profiles" for different use cases. Maybe we could develop a SAML profile for WSRP?

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.

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).

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). Then SAML with WS Security starts to look quite complex.

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

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

-----Original Message-----
From: richard.jacob@de.ibm.com [mailto:richard.jacob@de.ibm.com]
Sent: 20 July 2004 18:33
To: wsrp-interfaces@lists.oasis-open.org
Subject: [wsrp-interfaces] Groups - LeveraginSecurityStack-Strawman.ppt uploaded

The document LeveraginSecurityStack-Strawman.ppt has been submitted by Richard Jacob (richard.jacob@de.ibm.com) to the WSRP Interfaces SC document repository.

Document Description:
First draft of strawman.

Download Document: 
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/7839/LeveraginSecurityStack-Strawman.ppt

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=7839


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.



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