Hi Sebastien, Please find my comments inline. Thanks.
- Venkat On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > 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? > First, the comparison of policysets is dependent on the mechanisms supported by the policies that they embed. For example WS-Policy has prescribed mechanism to calculate intersection of two policy instances to see if they are compatible or match. So the policysets could be different on either sides, but the policies embedded within need to compatible. Having said that, the policysets on the target is available for locally wired services. For services that are in a different runtime, I suppose the service interfaces must publish this information for example as some extensions to the wsdl. This is something that need further study and exploration. > > > > >> - 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. Thanks :). I'll work on this. Infact for a first cut I could just about see if I can aggregate definitions.xml in a way similar to our service configuration files. > > 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. > I think your interpretation is convincing. So I'll go an change the policyset resolution codes to skip looking for policysets if an intent is found either in the alwaysProvided or mayProvided list. > > >> - 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? > :). Here is how I see it since I didn't see a choice with this ;-). The 'handler' code is typically a hook for plugging in 'userid verification' mechanisms. These mechanisms could vary from one application to the other - one might use a simply xml user registry, one a rdbms, another a LDAP registry and so on, each of which need to be accessed and operated in a specific way. The security administrator is the one who might code these handlers with the required logic. The policy administrators might simply formulate a policyset that includes the name of this handler. The composite assembler will continue to declaratively use the defined policyset. The funny thing is, this callback handler has a completely different role in pure JAAS based authentication. Its a hook that goes and fetches the userid and password like displaying prompts and so on. Its function is not to 'verify' the userid and password. The verification is done by a LoginModule in JAAS. > > [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] > >
