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 <[EMAIL PROTECTED]> 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
