cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: Http Authentication Policy
Date Mon, 12 Mar 2007 18:42:46 GMT
Dan Diephouse wrote:
> I think the idea is that a UserPassSupplier could pull information from a
> variety of sources. I might want instantiate my supplier with a 
> reference to
> my database, in which case I could define my supplier as a bean in 
> spring,
> and then just reference that bean on the conduit:
>
> <http:conduit userPassSupplier="#fooSupplier"/>
>
> <bean id="fooSupplier">
>  <constructor-arg><ref>dataSource</ref></constructor-arg>
> </bean>
>
> Or I could be completely misunderstanding what you are talking about :-)
>

What I was concerned about was that the previous example seemed 
"configure" the http conduit first with a "policy" structure, and then 
"configure" that *policy* with some operational component in the middle.

The approach, modulo the particular syntax, is the less convolute, using 
spring to "wire" operational sub-components together.

Cheers,
-Polar
> - Dan
>
> On 3/12/07, Polar Humenn <phumenn@iona.com> wrote:
>>
>> 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?
>>
>> Cheers,
>> -Polar
>>
>>
>>
>> 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
>>
>>
>
>


Mime
View raw message