cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 15:59:42 GMT
Hi Dan,

Question 1.  Are you the 5th cylon?  I don't think cylons sleep :)

Not sure how this addresses your question, but I'd like to mention  
something about your WS-Security example.

First, I agree that there is a gap in WS-SecurityPolicy when it comes  
to the specification of key material or user information (such as a  
name or password); that typically is "left to the implementation".

But I want to make sure that the WS-Feature approach you are talking  
about doesn't tie us down to schema-generated types, when it comes to  
programmatic configuration of features.  For example, you have some  
example code:

> ServerFactoryBean sf = new ServerFactoryBean();
>
> feature = new WSSecurityFeature();
> feature.setTrustKeyStore(...);
> ...
> sf.addWSFeature(feature);
>
> Or in XML:
>
> <jaxws:endpoint ...>
>  <features>
>     <wssec:security>
>         ....
>     </wssec:security>
>  </features>
> </jaxws:endpoint>

(and equivalently with your policy snippet)

Does this mean that I would be limited, in my feature.setTrustKeyStore 
(...) operation to passing in a string, e.g., a file path to a  
keystore on disk, or (recursively), a schema-generated struct that  
contains a string?

I have a real problem with that approach, which I can illustrate with  
an anecdote.  It turns out that Apple, for example, ships a Keystore  
implementation that provides a front-end to the user's KeyChain --  
this is a place to *securely* place keys, passwords, notes --  
whatever you want, really.  But the thing about this is, you don't  
load the keystore off the file system -- you get to it through  
operating system calls.  But all of the ugly nitty gritty details  
about how this is done are hidden by the keystore implementation.  As  
a Java programmer, you just to a Keystore.getInstance() with the  
right parameters.  I presume Windows users have similar access their  
user-level keys and certificates.

So this is a case-in-point where you might have a POJO you want to  
use to initialize a feature, as it were -- as aI suspect there are  
others.  I don't know enough about our code generators to know if you  
can put a POJO on a schema-generated type without violating any  
implicit contracts.  Maybe you can, maybe you can't.  Maybe the fact  
that you can now is an implementation detail that will change in the  
future.  (If anyone knows the answers to these questions, please  
advise!)

So that's the only constraint I would like to see on WS-Features --  
the ability to use POJOs with them, and not to be forced down to the  
LCD that is XML schema.

-Fred

Mime
View raw message