Communicating Security Policies

[Darrin Norwood <dsn9620@yahoo.com>]

I have a few questions for the Members of the OASIS Web Services Security (WSS) TC
about best practices for communicating security policies to web service consumers.

1. The security layer for the provider web services that I am building requires user credentials that don't easily map to the defined tokens (username, saml, x.509, etc.) since it's a homegrown solution.  The credentials include a username, password, and an alphanumeric key.  The web service is hosted over SSL and the credentials are not required to be signed.  I could specify the use of the username token plus one addition custom token (a homegrown schema to define the alphanumeric key element) in the policy document or I could just create a custom token that has contains username, passwd, and alphanum key.  There are possibly other methods but what is the most appropriate way to define a policy for this situation?

2. Should custom tokens ever need to be defined? In other words, is there (can there be) a way that the web service provider developer can extend one of the existing token types by adding syntax in the policy document that can be understood by web service consumers?

3. Consumers of my web services are complaining that it is difficult to consume a security policy (WS-SecurityPolicy) document. Their expectation is that the security policy should be as easy to consume as a WSDL and it should allow them to produce the stubs necessary to interact with a provider web service.  It is also difficult for them to understand how a security policy document should be used. I attribute this for the most part to the fact that it is an emerging standard.  At this time then, what is the simplest, most effective, and acceptable way to communicate the security policy for the a web service for consumers and their tools that don't understand WS-Policy, WS-SecurityPolicy, and WS-PolicyAttachment?  Purists state that security should not be specified by messages in the WSDL, but it seems to be the easiest way today to communicate and consume the security requirements.  So it's confusing to know what the right direction is going forward.

4. Is the SecurityPolicy document intended to be a runtime consumable or a compile time consumable?  The security policy use cases posted seem to suggest that it is a runtime consumable.  In practice I've only see consumption of the security policy occuring when the web service consumer is being built.

Regards,
Darrin Norwood


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting