Venkata Krishnan wrote:
- Why did you need two authentication and wsAuthentication intents? is
it because you needed different policy sets on the client and service
side?
Yes, that's the reason. Since the policysets encapsulate things like the
username, password callback hander etc. which could be different for the
client and the server there needed to be different policysets. Having the
same intent does no guarantee that the right policyset will be matched i.e.
the client's policyset for the reference and the server's policyset for the
service. Having unique intents will ensure this mapping.
I'm not getting it sorry :)
Why are the wired reference and target service policysets different?
If they are different how do you validate that wiring the reference to
the service is allowed?
- Did you have to change the WS binding code to support your new user
defined wsAuthentication intent?
No. Just to clarify, the mapping of policysets to intents is done by the
core runtime.
Good
- Is there a way to not repeat the core intents defined by the spec in
all contributions?
No. This is one of the concerns I have and could be resolved by having
multiple definitions.xml files.
OK, here are some suggestions to improve that:
To allow an admin to configure policies on a domain basis and on a
contribution basis:
- Package Definitions.xml files in SCA contributions contributed to the
domain.
- Assume that definitions in the SCA namespace are available in the
whole domain.
- Import definitions from user namespaces using the standard SCA XML
<import> mechanism.
To describe the capabilities of binding and implementation runtimes:
- Package a definitions.xml file in their JARs
- Containing relevant bindingType and implementationType definitions.
We should ask the policy spec folks how they envision definitions.xml
being authored and used.
Also the various artifacts in a composite
would like to enforce a particular intent say 'authentication' in their own
respective ways for which there may be appropriate policysets defined.
Mapping authentication to different policysets for different artifacts is
not possible. Am not sure if the specs meant that all artifacts should use
just about one type of realization of an intent.
Not sure, that's a good question for the spec folks.
- Where are the bindingType definitions listing the intents provided by
the bindings?
I had deliberately kept this out of this scenario to help us arrive at its
usage. The 'constrains' attribute of Intents is what is being used to
figure out the intents supported by the bindingType or ImplType. Now as I
am writing this I see that a right way to see if an intent is supported on a
bindingtype or implTyp is to check against the BindingType or
ImplementationType definitions.
My understanding was different:
- if alwaysProvided -> the binding always assumes that the intent is set
- if mayProvide -> you can set the intent without specifying a policySet
- else, you are allowed to set the intent on a binding if there is a
policyset that says provides = that intent and appliesTo = that binding.
This also leads me to think that for every
intent 'mayProvided' by a bindingType there is just one mapping policyset
that will be used.
I thought that mayProvide didn't require a policyset. I may have
mis-understood, that's another question for the spec folks.
- What are the security callback handlers responsible for?
Until I looked at JAAS yesterday, I thought they are the hooks that the
bindings will call to enable applications to go off into user registries and
perform authentication. Looking at JAAS it seems like the callback handlers
are typically used to 'fetch' the username and password. There is a
LoginModule that actually encapsulates how and against what sort of user
registry these things are authenticated and its the LoginModule that calls
these handlers to simply fetch the user or client inputs. I must dig up
Rampart to see if this is what it also intends.
Not sure I like that. Doing all this policy stuff to provide declarative
policies in XML and then eventually say "you have to write to
javax.security aware piece of code to provide a user and password" [1]
doesn't sound like a great story to me. Thoughts?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/AccountsDataPasswordCallbackHandler.java
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
