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
