Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Hi, Going further with the Bigbank scenario I have now split up the three different accounts - Savings, Stock and Checkings into individual composites. The checkingAccount service is exposed as a webservice and is enabled for authentication. Now I am trying to incorporate authorization into the checkingsAccount implementation i.e. allow access of account information only to its owners. The authentication of users happens at the wsBinding and the authenticated principal must now be used for authorization by the checkingsAccount java implementation. I spent a bit of time exploring how I could fit in a JAAS into this scenario and just could not figure out a neat fit. JAAS authorization seems to be good when we are treating things as just java resources. But over here it seems to me that we are doing things at the application layer. So for now I plan to resort to a more higher level authorization where I plan to maintain a access control list that will provide a list of which user owns which account. With this, I am figuring out how the authenticated principal could be passed over from the wsBinding to the javaImplementation. Obviously the Message object seems to be the only viable carrier and am trying somethings around that. Will post next on what actually works at the end of all this. Meanwhile, thoughts / suggestions ? Thanks - Venkat
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Hi, Continuing with the secure-bigbank demo, I have got the checkings account webservice to pass the authenitcated principal to the java implementation that inturn authorizes the principal. I have made changes to Message, MessageImpl and the Axis2 binding for this (r607209). We can evolve or change this as we mull over the goods and bads of this ;-). Heres the story I have assumed... - the checkings department has decided to put in authorization where it would only allow the owners to access their accounts. Accordingly it has come up with a 'access control mechanism' for this authorization. - to plug in this authorization, the PolicyAdminstrator - defines a policy handler from which authorization calls can me made out to this 'access control mechanism' - defines an intent and a matching policyset that would be able to affect this particular mechanism for authorization i.e. call out this defined handler. - the composite assembler marks the CheckingAccountService component's implementation as 'requires=ck:authorization'. Issues / Points to ponder 1) Here we expect applications to be defining their own policyhandlers. Since policy handlers are defined in a services configuration file, here the checkings application contributes to one such file. Though I have been able to run the sample in eclipse and mvn, the 'ant' driven one does not work. I suspect this is due to some classloader issues related to the loading of the services configuration file defined by the application 2) Since applications define their policy handlers, I've had to include the 'core' as a dependency since these handlers have to work with the 'Message' class. Thoughts / suggestions :) ? Thanks - Venkat On Dec 27, 2007 3:37 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi, > > Going further with the Bigbank scenario I have now split up the three > different accounts - Savings, Stock and Checkings into individual > composites. > > The checkingAccount service is exposed as a webservice and is enabled for > authentication. Now I am trying to incorporate authorization into the > checkingsAccount implementation i.e. allow access of account information > only to its owners. > > The authentication of users happens at the wsBinding and the authenticated > principal must now be used for authorization by the checkingsAccount java > implementation. > > I spent a bit of time exploring how I could fit in a JAAS into this > scenario and just could not figure out a neat fit. JAAS authorization seems > to be good when we are treating things as just java resources. But over > here it seems to me that we are doing things at the application layer. So > for now I plan to resort to a more higher level authorization where I plan > to maintain a access control list that will provide a list of which user > owns which account. > > With this, I am figuring out how the authenticated principal could be > passed over from the wsBinding to the javaImplementation. Obviously the > Message object seems to be the only viable carrier and am trying somethings > around that. Will post next on what actually works at the end of all this. > Meanwhile, thoughts / suggestions ? > > Thanks > > - Venkat >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Hi, Now this demo works from the 'ant' build as well. There was a problem with the ordering of the PolicyHandling Interceptor along the invocation chain. It quite strange how this varies depending on whether its executed within eclipse or outside. I have put in a fix that works both ways. - Venkat On Dec 28, 2007 5:04 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi, > > Continuing with the secure-bigbank demo, I have got the checkings account > webservice to pass the authenitcated principal to the java implementation > that inturn authorizes the principal. I have made changes to Message, > MessageImpl and the Axis2 binding for this (r607209). We can evolve or > change this as we mull over the goods and bads of this ;-). > > Heres the story I have assumed... > - the checkings department has decided to put in authorization where it > would only allow the owners to access their accounts. Accordingly it has > come up with a 'access control mechanism' for this authorization. > > - to plug in this authorization, the PolicyAdminstrator >- defines a policy handler from which authorization calls can me > made out to this 'access control mechanism' >- defines an intent and a matching policyset that would be able to > affect this particular mechanism for authorization i.e. call out this > defined handler. > > - the composite assembler marks the CheckingAccountService component's > implementation as 'requires=ck:authorization'. > > Issues / Points to ponder > > 1) Here we expect applications to be defining their own policyhandlers. > Since policy handlers are defined in a services configuration file, here the > checkings application contributes to one such file. Though I have been able > to run the sample in eclipse and mvn, the 'ant' driven one does not work. I > suspect this is due to some classloader issues related to the loading of the > services configuration file defined by the application > > 2) Since applications define their policy handlers, I've had to include > the 'core' as a dependency since these handlers have to work with the > 'Message' class. > > Thoughts / suggestions :) ? > > Thanks > > - Venkat > > > > On Dec 27, 2007 3:37 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Going further with the Bigbank scenario I have now split up the three > > different accounts - Savings, Stock and Checkings into individual > > composites. > > > > The checkingAccount service is exposed as a webservice and is enabled > > for authentication. Now I am trying to incorporate authorization into the > > checkingsAccount implementation i.e. allow access of account information > > only to its owners. > > > > The authentication of users happens at the wsBinding and the > > authenticated principal must now be used for authorization by the > > checkingsAccount java implementation. > > > > I spent a bit of time exploring how I could fit in a JAAS into this > > scenario and just could not figure out a neat fit. JAAS authorization seems > > to be good when we are treating things as just java resources. But over > > here it seems to me that we are doing things at the application layer. So > > for now I plan to resort to a more higher level authorization where I plan > > to maintain a access control list that will provide a list of which user > > owns which account. > > > > With this, I am figuring out how the authenticated principal could be > > passed over from the wsBinding to the javaImplementation. Obviously the > > Message object seems to be the only viable carrier and am trying somethings > > around that. Will post next on what actually works at the end of all this. > > Meanwhile, thoughts / suggestions ? > > > > Thanks > > > > - Venkat > > > >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
+1. I will start looking into this after I am done with some half-finished things on my plate at the moment. Thanks. - Venkat On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Greg Dritschler wrote: > > Is the authentication policy going to bear any resemblance to the policy > > described in section 1.7.3.1 of the Policy spec, or is it completely > > different? > > > > Greg > > > > I think that Tuscany should implement the authorization - I guess that's > what you meant :) - and security identity policies as described in > section 1.7.3.1 of the Policy spec, at least. > > We could start with just implementing the model and XML reading for the > elements described in 1.7.3.1 and let the various component > implementation extensions handle them (or not) in their own way, but > having the model and XML processors would be a good start IMO. > > Any thoughts? > -- > Jean-Sebastien > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Greg Dritschler wrote: Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg I think that Tuscany should implement the authorization - I guess that's what you meant :) - and security identity policies as described in section 1.7.3.1 of the Policy spec, at least. We could start with just implementing the model and XML reading for the elements described in 1.7.3.1 and let the various component implementation extensions handle them (or not) in their own way, but having the model and XML processors would be a good start IMO. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Ok. Please be aware there is an errata associated with the authorization elements. http://www.osoa.org/jira/browse/POLICY-26 On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > +1. I will start looking into this after I am done with some > half-finished > things on my plate at the moment. Thanks. > > - Venkat > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > Greg Dritschler wrote: > > > Is the authentication policy going to bear any resemblance to the > policy > > > described in section 1.7.3.1 of the Policy spec, or is it completely > > > different? > > > > > > Greg > > > > > > > I think that Tuscany should implement the authorization - I guess that's > > what you meant :) - and security identity policies as described in > > section 1.7.3.1 of the Policy spec, at least. > > > > We could start with just implementing the model and XML reading for the > > elements described in 1.7.3.1 and let the various component > > implementation extensions handle them (or not) in their own way, but > > having the model and XML processors would be a good start IMO. > > > > Any thoughts? > > -- > > Jean-Sebastien > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Hi, With r650032, I have committed some simple additions to support the model and StaX processor for the bunch of policy assertions specified in section 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. I'd wish to optimize this a bit and cut down on some classes in the future. As a start for this here is a question related to the specs and hope somebody is able to help me with some clarity... - Do we need three assertions viz. permitAll, denyAll, allow. Why not just the one as follows: - So if permitAll is 'true' then all roles is permitted. If it is false then only those roles in the 'roles' attribute is permitted. If it is false and there aren't any roles specified then it is equivalent to 'denyAll'. Thanks - Venkat On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler <[EMAIL PROTECTED]> wrote: > Ok. Please be aware there is an errata associated with the authorization > elements. > http://www.osoa.org/jira/browse/POLICY-26 > > On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan <[EMAIL PROTECTED]> > wrote: > > > +1. I will start looking into this after I am done with some > > half-finished > > things on my plate at the moment. Thanks. > > > > - Venkat > > > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > > > Greg Dritschler wrote: > > > > Is the authentication policy going to bear any resemblance to the > > policy > > > > described in section 1.7.3.1 of the Policy spec, or is it completely > > > > different? > > > > > > > > Greg > > > > > > > > > > I think that Tuscany should implement the authorization - I guess > that's > > > what you meant :) - and security identity policies as described in > > > section 1.7.3.1 of the Policy spec, at least. > > > > > > We could start with just implementing the model and XML reading for > the > > > elements described in 1.7.3.1 and let the various component > > > implementation extensions handle them (or not) in their own way, but > > > having the model and XML processors would be a good start IMO. > > > > > > Any thoughts? > > > -- > > > Jean-Sebastien > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Hi, I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted proposal? Thanks, Raymond -- From: "Venkata Krishnan" <[EMAIL PROTECTED]> Sent: Monday, April 21, 2008 12:20 AM To: Subject: Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario Hi, With r650032, I have committed some simple additions to support the model and StaX processor for the bunch of policy assertions specified in section 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. I'd wish to optimize this a bit and cut down on some classes in the future. As a start for this here is a question related to the specs and hope somebody is able to help me with some clarity... - Do we need three assertions viz. permitAll, denyAll, allow. Why not just the one as follows: - So if permitAll is 'true' then all roles is permitted. If it is false then only those roles in the 'roles' attribute is permitted. If it is false and there aren't any roles specified then it is equivalent to 'denyAll'. Thanks - Venkat On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler <[EMAIL PROTECTED]> wrote: Ok. Please be aware there is an errata associated with the authorization elements. http://www.osoa.org/jira/browse/POLICY-26 On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > +1. I will start looking into this after I am done with some > half-finished > things on my plate at the moment. Thanks. > > - Venkat > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > Greg Dritschler wrote: > > > Is the authentication policy going to bear any resemblance to the > policy > > > described in section 1.7.3.1 of the Policy spec, or is it > > > completely > > > different? > > > > > > Greg > > > > > > > I think that Tuscany should implement the authorization - I guess that's > > what you meant :) - and security identity policies as described in > > section 1.7.3.1 of the Policy spec, at least. > > > > We could start with just implementing the model and XML reading for the > > elements described in 1.7.3.1 and let the various component > > implementation extensions handle them (or not) in their own way, but > > having the model and XML processors would be a good start IMO. > > > > Any thoughts? > > -- > > Jean-Sebastien > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
I don't know whether the POLICY-26 proposal has been accepted. I think POLICY-26 is a bit clearer in conveying the meaning of the different choices than Venkat's proposal. While POLICY-26 fixes the schema so that conflicting authorization elements cannot be specified within a policy set, it does not address what should happen when authorization policy is inherited across levels. The framework says policy sets are additive and clearly this can result in conflicts. I guess one could say that this is an error in the composite. However that limits the use of inheritance for this type of policy because then one can't establish a default policy for the composite and override for particular components. On Mon, Apr 21, 2008 at 7:30 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know > if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted > proposal? > > Thanks, > Raymond > -- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > Sent: Monday, April 21, 2008 12:20 AM > To: > Subject: Re: Authentication & Authorization across wsBinding & java > Implementation - was : Using security policies in the Bigbank scenario > > > Hi, > > > > With r650032, I have committed some simple additions to support the > > model > > and StaX processor for the bunch of policy assertions specified in > > section > > 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. > > > > I'd wish to optimize this a bit and cut down on some classes in the > > future. > > As a start for this here is a question related to the specs and hope > > somebody is able to help me with some clarity... > > > > - Do we need three assertions viz. permitAll, denyAll, allow. Why not > > just > > the one as follows: - > > > > > > So if permitAll is 'true' then all roles is permitted. If it is false > > then > > only those roles in the 'roles' attribute is permitted. If it is false > > and > > there aren't any roles specified then it is equivalent to 'denyAll'. > > > > Thanks > > > > - Venkat > > > > On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler < > > [EMAIL PROTECTED]> > > wrote: > > > > Ok. Please be aware there is an errata associated with the > > > authorization > > > elements. > > > http://www.osoa.org/jira/browse/POLICY-26 > > > > > > On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan < > > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > +1. I will start looking into this after I am done with some > > > > half-finished > > > > things on my plate at the moment. Thanks. > > > > > > > > - Venkat > > > > > > > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > Greg Dritschler wrote: > > > > > > Is the authentication policy going to bear any resemblance to > > > the > > > > policy > > > > > > described in section 1.7.3.1 of the Policy spec, or is it > > > > > > completely > > > > > > different? > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > I think that Tuscany should implement the authorization - I guess > > > that's > > > > > what you meant :) - and security identity policies as described in > > > > > section 1.7.3.1 of the Policy spec, at least. > > > > > > > > > > We could start with just implementing the model and XML reading > > > for > > > the > > > > > elements described in 1.7.3.1 and let the various component > > > > > implementation extensions handle them (or not) in their own way, > > > but > > > > > having the model and XML processors would be a good start IMO. > > > > > > > > > > Any thoughts? > > > > > -- > > > > > Jean-Sebastien > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario
Anyway, I checked in the updated model and processors under http://svn.apache.org/viewvc?rev=650652&view=rev. The processors can handle both syntax. Please see the ProcessorTestCase. Thanks, Raymond -- From: "Greg Dritschler" <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2008 8:26 AM To: Subject: Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario I don't know whether the POLICY-26 proposal has been accepted. I think POLICY-26 is a bit clearer in conveying the meaning of the different choices than Venkat's proposal. While POLICY-26 fixes the schema so that conflicting authorization elements cannot be specified within a policy set, it does not address what should happen when authorization policy is inherited across levels. The framework says policy sets are additive and clearly this can result in conflicts. I guess one could say that this is an error in the composite. However that limits the use of inheritance for this type of policy because then one can't establish a default policy for the composite and override for particular components. On Mon, Apr 21, 2008 at 7:30 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted proposal? Thanks, Raymond -- From: "Venkata Krishnan" <[EMAIL PROTECTED]> Sent: Monday, April 21, 2008 12:20 AM To: Subject: Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario Hi, > > With r650032, I have committed some simple additions to support the > model > and StaX processor for the bunch of policy assertions specified in > section > 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. > > I'd wish to optimize this a bit and cut down on some classes in the > future. > As a start for this here is a question related to the specs and hope > somebody is able to help me with some clarity... > > - Do we need three assertions viz. permitAll, denyAll, allow. Why not > just > the one as follows: - > > > So if permitAll is 'true' then all roles is permitted. If it is false > then > only those roles in the 'roles' attribute is permitted. If it is > false > and > there aren't any roles specified then it is equivalent to 'denyAll'. > > Thanks > > - Venkat > > On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler < > [EMAIL PROTECTED]> > wrote: > > Ok. Please be aware there is an errata associated with the > > authorization > > elements. > > http://www.osoa.org/jira/browse/POLICY-26 > > > > On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan < > > [EMAIL PROTECTED]> > > wrote: > > > > > +1. I will start looking into this after I am done with some > > > half-finished > > > things on my plate at the moment. Thanks. > > > > > > - Venkat > > > > > > On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino < > > > [EMAIL PROTECTED]> wrote: > > > > > > > Greg Dritschler wrote: > > > > > Is the authentication policy going to bear any resemblance to > > the > > > policy > > > > > described in section 1.7.3.1 of the Policy spec, or is it > > > > > completely > > > > > different? > > > > > > > > > > Greg > > > > > > > > > > > > > I think that Tuscany should implement the authorization - I guess > > that's > > > > what you meant :) - and security identity policies as described > > > > in > > > > section 1.7.3.1 of the Policy spec, at least. > > > > > > > > We could start with just implementing the model and XML reading > > for > > the > > > > elements described in 1.7.3.1 and let the various component > > > > implementation extensions handle them (or not) in their own way, > > but > > > > having the model and XML processors would be a good start IMO. > > > > > > > > Any thoughts? > > > > -- > > > > Jean-Sebastien > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
