[wsf-c-dev] [wsf-php] Security Implementation

[James Clark]

> In case 1, we will obtain the policy file location from user and 
> construct an axiom structure and pass to rampart and it will handle the 
> rest.

For reasons I've explained before, the PHP option should take the XML
policy (as SimpleXML or a DOM or a string) not the filename.

It also might be good to introduce a WSPolicy object:

- introduce a WSPolicy object

- be able to construct a WSPolicy from SimpleXML/DOM/string

- be able to get SimpleXML/DOM/string from a WSPolicy

- be able to create a WSPolicy by combining two or more policys in
various ways according to the semantics defined by the policy specs

This has two benefits:

- it allows policies to be combined

- it allows the implementation to avoid unnecessary conversions from the
XML representation of a policy to its internal representation

> In case 2, we will construct a axiom structure of a policy file using 
> the user provided options and pass it to rampart.

+1.  I think this sort of policy-centric approach is definitely the way
to go.

> Necessary values for security will be obtained from the user using 
> opaque type WSSecurityToken and associated convenient functions  which 
> were discussed in a previous thread.

+1. Apart from policy, security credentials (i.e. the WSSecurityToken)
is clearly one of the other fundamental category of things that the user
needs to specify.

The other kind of thing I wonder about is information needed for
performing authentication and authorization.  There are some policy
aspects to this, but I feel a bit uneasy about modelling this completely
as policy.

James