Wonderful, thats really good! ..ant
On Jan 3, 2008 4:41 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi, > > I have now changed things to allow for multiple definitions.xml file. > The > contents of the various definitions.xml file for a domain are all > aggregated. The runtime and extensions can contribute sca definitions > with > a definitions.xml in the META-INF/services directory while contributions > can > also have their definitions.xml as any other artifact. > > With this contributions need not redefine the intents supported by the > Tuscany runtime and can assume them to be available to them. > > Thanks > > - Venkat > > On Dec 26, 2007 4:56 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > >
