Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.

[Venkata Krishnan <fo...@gmail.com>]

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 <fo...@gmail.com> wrote:

> Hi Sebastien,
>
> Please find my comments inline.  Thanks.
>
> - Venkat
>
> On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <jsdelfino@apache.org >
> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.

[ant elder <an...@gmail.com>]

Wonderful, thats really good!

   ..ant

On Jan 3, 2008 4:41 PM, Venkata Krishnan <fo...@gmail.com> 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 <fo...@gmail.com> wrote:
>
> > Hi Sebastien,
> >
> > Please find my comments inline.  Thanks.
> >
> > - Venkat
> >
> > On Dec 15, 2007 2:52 AM, Jean-Sebastien Delfino <jsdelfino@apache.org >
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>