cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Http Authentication Policy
Date Mon, 12 Mar 2007 18:30:09 GMT
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 :-)

- 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
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message