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

[Samisa Abeysinghe]

James Clark wrote:
>> 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.
>   
Looking at a security policy file, I think that not many PHP users would 
ever take the trouble of understanding that.
Hence, what would be the benefit of taking that as SimpleXML or DOM? I 
think, for many users, it would be far simple to drop the policy file 
somewhere and use it.
IMHO, case 2 mentioned below would be the most preferable use case for 
PHP users.

Samisa...
> 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
>
>
>
>
> _______________________________________________
> Wsf-c-dev mailing list
> Wsf-c-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>
>   


-- 
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)