cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Re: Http Authentication Policy
Date Mon, 12 Mar 2007 15:12:24 GMT
As Fred mentioned the difference between Own and Received Credentials in 
an effort to maintain separation from "configuration" and "rutime 
attributes", I would like to make a distinction of what is 
"configuration" and what is "policy". There may be a fine line that I'm 
sure will insight arguments :)

"Configuring" an http-conduit to use a particular UserPassSupplier is 
what I would consider "configuration" and seems to be an acceptable use 
of Spring configuration (for those things the code writer and the 
deployment engineer know need to be configured apriori).

However, placing things like "reactive" authorization "policy" in a the 
"configuration" space seems to muddle the waters between this 
separation.  I would like to see spring used at the conduit layer to 
"hook" together the various components needed to get the job done, and 
have those components query various policy structures if need be.

Why does a conduit need to "configured" with anything more than a 
particular UserPassSupplier?


Fred Dushin wrote:
> On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
>> Yep, fair point about the UserPassSupplier possibly requiring more
>> context than could be provided via a simple no-arg ctor called via
>> Class.forName().
>> This could be addressed by making the UserPassSupplier a Spring bean (so
>> that its dependencies are injected), but then <ref>erring to this bean
>> from within the AuthPolicy of the http-conduit bean (so that the
>> UserPassSupplier is now a dependency of the http-conduit bean, as
>> opposed to a completely free-standing bean).
> Excellent -- this seems workable to me.  Another option would of 
> course be to dynamically load and instantiate via a more "interesting" 
> ctor, but I am beginning to understand the benefits of Spring here -- 
> defining said ctor would require definition of some sort of contract 
> ("You must define a public ctor that takes a map, such that ... 
> etc").  With a bean, it's all more or less done for you (if you can 
> figure out what "it" is :)
>> Yep, good point, we should probably replace the reuse of
>> AuthorizationPolicy in the receiving context, with a separate
>> AuthorizationContext or somesuch.
> Yes, let's make sure things in the "configuration" namespace are used 
> for configuration, not for anything else.
>> But if you want to go ahead and consolidate the common elements of these
>> policies into a single base type, I'd be +1.
> Sure, I'll try -- I also at one point tried to generate my own PKCS12 
> file and trustdb, but ran into a wall.  I'll try to revitalize that 
> effort, at well, and document what I find are the requirements.  My 
> first pass failed for reasons I could not explain.
> -Fred

View raw message