On Wed, Feb 23, 2011 at 4:50 PM, Prabath Siriwardana <[email protected]>wrote:
> Hi Paul, > > Mostly the complexity of XACML policy lies on - because of the > difficulty in defining the policy.. > > Asela has developed a UI wizard - which includes a basic and advanced > - two wizards to define a XACML policy.. So I guess this would make it > easy.. > > Also - we are planning to have Entitlement as a module - so can be > consumed directly by AS and DSS.. > > Row level / column level authorization via XACML was once came as a > customer requirement too... > > Shall we look in to how this DSS requirement can be integrated with > the XACML support in IS... > As Paul mentioned there are two types of authorizations, 1. Service/operation authorization 2. Service specific authorization - DSS, SQS, topics, registry resources etc .. Later is almost implemented using carbon authorization manager and there are few missing parts with service/operation authorization. So I think it is better to first finish it and think how XACML can be used across the carbon platform. thanks, Amila. > Thanks & regards, > -Prabath > > > > On Wed, Feb 23, 2011 at 4:16 PM, Paul Fremantle <[email protected]> wrote: > > Amila > > I agree we don't want too many options, but I believe the entitlement > > mediator is a sort of special case. > > Basically the way I see it is that XACML is very complex and powerful and > so > > we have that as a special option for advanced use cases. > > So really I do see a need for three levels of security: > > 1) Optional XACML gateway layer based on ESB+Entitlement mediator. > > 2) Service level security - generic facilities across the platform (this > is > > where the operation facility should apply as well, since it applies to > all > > types of service) > > 3) Service-type-specific security: there are some things which are unique > to > > a particular service type: e.g. row-level or column-level security in > DSS. > > This kind of thing has to be implemented at the DSS layer. > > Paul > > On 23 February 2011 06:58, Amila Suriarachchi <[email protected]> wrote: > >> > >> > >> On Wed, Feb 23, 2011 at 11:46 AM, Anjana Fernando <[email protected]> > wrote: > >>> > >>> Hi, > >>> > >>> On Wed, Feb 23, 2011 at 11:09 AM, Amila Suriarachchi <[email protected]> > >>> wrote: > >>> > In users point of view they need to tell, only these roles can access > >>> > these > >>> > operations. They don't need to define a special permission for that. > >>> > > >>> > If go to the UT scenario in security wizard, it allows users to > assign > >>> > a > >>> > role to a service access. What we need is to extend that to operation > >>> > level > >>> > without depending on the UT only. > >>> > > >>> > >>> Also, as Dimuthu explained, we've to explicitly go and edit the > >>> services.xml of a service. But we do not have another mechanism where > >>> we can use the Carbon UI to define these, so for service types which > >>> doesn't have a services.xml (I guess in rules server / MS they don't > >>> have it) we cannot do this. > >> > >> you can use carbon service dash board to add operation level parameters. > >> But what I really worry about this permission thing. > >> > >> In other words there are three ways assign to authorization to > >> service/operations in carbon. > >> > >> 1. Use operation/service level parameter to specify permission, then > >> assign permission to role. > >> 2. With UT directly assign role to service > >> 3. For ESB proxy services use entitlement mediator. > >> > >> But I think what we need is a one simple unique way to assign roles to > >> services/operations independent of authentication. > >> > >> thanks, > >> Amila. > >> > >> > >>> > >>> Cheers, > >>> Anjana. > >>> > >>> > In the way you have told, how users suppose to assign the permission > to > >>> > role. is this permission get appeared in the permission tree? > >>> > > >>> > thanks, > >>> > Amila. > >>> > > >>> > > >>> > > >>> >> > >>> >> Thanks, > >>> >> Dimuthu > >>> >> > >>> >> On Wed, Feb 23, 2011 at 10:06 AM, Anjana Fernando <[email protected]> > >>> >> wrote: > >>> >>> > >>> >>> On Wed, Feb 23, 2011 at 9:30 AM, Srinath Perera <[email protected]> > >>> >>> wrote: > >>> >>> > Others == IS guys , just FYI > >>> >>> > >>> >>> Yep OK. > >>> >>> > >>> >>> Cheers, > >>> >>> Anjana. > >>> >>> > >>> >>> > > >>> >>> > On Wed, Feb 23, 2011 at 9:27 AM, Anjana Fernando < > [email protected]> > >>> >>> > wrote: > >>> >>> >> Hi, > >>> >>> >> > >>> >>> >> On Wed, Feb 23, 2011 at 9:21 AM, Srinath Perera < > [email protected]> > >>> >>> >> wrote: > >>> >>> >>> Hi Anjana, > >>> >>> >>> > >>> >>> >>> What you need is to say something like > >>> >>> >>> > >>> >>> >>> "only admin role can invoke updateUserOperation in a Data > >>> >>> >>> Service" > >>> >>> >>> > >>> >>> >>> Am I right? > >>> >>> >> > >>> >>> >> Yes, exactly. > >>> >>> >> > >>> >>> >>> > >>> >>> >>> I was under the impression we already have this feature (Please > >>> >>> >>> talk > >>> >>> >>> to IS guys). If not, it is matter of writing a Axis2 Handler > >>> >>> >>> > >>> >>> >>> 1. Please do not define this within DSS only > >>> >>> >>> 2. If it is not there, this is useful across the platform, so > >>> >>> >>> negotiate with others, but if you going to do that, you must do > >>> >>> >>> it at > >>> >>> >>> carbon level and check in as a componant and get others to use > >>> >>> >>> it. > >>> >>> >>> 3. Config info should go in axis2.xml I think. > >>> >>> >>> > >>> >>> >> > >>> >>> >> Sure OK, will talk to others and see. > >>> >>> >> > >>> >>> >> Cheers, > >>> >>> >> Anjana. > >>> >>> >> > >>> >>> >>> --Srinath > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> On Tue, Feb 22, 2011 at 8:35 PM, Anjana Fernando > >>> >>> >>> <[email protected]> > >>> >>> >>> wrote: > >>> >>> >>>> Hi, > >>> >>> >>>> > >>> >>> >>>> We've a requirements in DSS to restrict access to operations > for > >>> >>> >>>> specific user roles. We use a similar method to do content > >>> >>> >>>> filtering > >>> >>> >>>> by associating a required role to a specific data output > field. > >>> >>> >>>> So a > >>> >>> >>>> possibility to achieve the same behaviour for service > operation > >>> >>> >>>> invocation, > >>> >>> >>>> > >>> >>> >>>> * Use the data service's associated external services.xml to > >>> >>> >>>> define > >>> >>> >>>> these restrictions for service operations. > >>> >>> >>>> * Use the data service description file (.dbs file) to define > >>> >>> >>>> these > >>> >>> >>>> properties as we do with content filtering. > >>> >>> >>>> > >>> >>> >>>> The editing the .dbs maybe more convenient to the user in a > way > >>> >>> >>>> that, > >>> >>> >>>> then the data service is self contained and it will not depend > >>> >>> >>>> on > >>> >>> >>>> another service.xml file, to define such behaviour. Currently > >>> >>> >>>> the > >>> >>> >>>> services.xml in data service is mainly used for special > >>> >>> >>>> functionality > >>> >>> >>>> such as setting axis2 service parameters, for making it an > >>> >>> >>>> admin/hidden service and so on. > >>> >>> >>>> > >>> >>> >>>> I was talking with Amila earlier and his idea is, this should > be > >>> >>> >>>> a > >>> >>> >>>> general feature that should be common to all services and this > >>> >>> >>>> type > >>> >>> >>>> of > >>> >>> >>>> functionality should be defined in the security wizard. So > will > >>> >>> >>>> such > >>> >>> >>>> a > >>> >>> >>>> feature be added in the near by future? .. or shall we > continue > >>> >>> >>>> by > >>> >>> >>>> defining our own functionality into DSS. Any thoughts are > >>> >>> >>>> welcome. > >>> >>> >>>> > >>> >>> >>>> Cheers, > >>> >>> >>>> Anjana. > >>> >>> >>>> > >>> >>> >>>> -- > >>> >>> >>>> Anjana Fernando > >>> >>> >>>> Software Engineer > >>> >>> >>>> WSO2, Inc.; http://wso2.com > >>> >>> >>>> lean.enterprise.middleware > >>> >>> >>>> _______________________________________________ > >>> >>> >>>> Carbon-dev mailing list > >>> >>> >>>> [email protected] > >>> >>> >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>> >>> >>>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> -- > >>> >>> >>> ============================ > >>> >>> >>> Srinath Perera, Ph.D. > >>> >>> >>> Senior Software Architect, WSO2 Inc. > >>> >>> >>> Visiting Lecturer, University of Moratuwa > >>> >>> >>> Member, Apache Software Foundation > >>> >>> >>> Research Scientist, Lanka Software Foundation > >>> >>> >>> Blog: http://srinathsview.blogspot.com/ > >>> >>> >>> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> -- > >>> >>> >> Anjana Fernando > >>> >>> >> Software Engineer > >>> >>> >> WSO2, Inc.; http://wso2.com > >>> >>> >> lean.enterprise.middleware > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > -- > >>> >>> > ============================ > >>> >>> > Srinath Perera, Ph.D. > >>> >>> > Senior Software Architect, WSO2 Inc. > >>> >>> > Visiting Lecturer, University of Moratuwa > >>> >>> > Member, Apache Software Foundation > >>> >>> > Research Scientist, Lanka Software Foundation > >>> >>> > Blog: http://srinathsview.blogspot.com/ > >>> >>> > > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> Anjana Fernando > >>> >>> Software Engineer > >>> >>> WSO2, Inc.; http://wso2.com > >>> >>> lean.enterprise.middleware > >>> >>> _______________________________________________ > >>> >>> Carbon-dev mailing list > >>> >>> [email protected] > >>> >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> Carbon-dev mailing list > >>> >> [email protected] > >>> >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>> >> > >>> > > >>> > > >>> > _______________________________________________ > >>> > Carbon-dev mailing list > >>> > [email protected] > >>> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Anjana Fernando > >>> Software Engineer > >>> WSO2, Inc.; http://wso2.com > >>> lean.enterprise.middleware > >> > >> > >> _______________________________________________ > >> Carbon-dev mailing list > >> [email protected] > >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >> > > > > > > > > -- > > Paul Fremantle > > CTO and Co-Founder, WSO2 > > OASIS WS-RX TC Co-chair, VP, Apache Synapse > > > > Office: +44 844 484 8143 > > Cell: +44 798 447 4618 > > > > blog: http://pzf.fremantle.org > > twitter.com/pzfreo > > [email protected] > > > > wso2.com Lean Enterprise Middleware > > > > Disclaimer: This communication may contain privileged or other > confidential > > information and is intended exclusively for the addressee/s. If you are > not > > the intended recipient/s, or believe that you may have received this > > communication in error, please reply to the sender indicating that fact > and > > delete the copy you received and in addition, you should not print, copy, > > retransmit, disseminate, or otherwise use the information contained in > this > > communication. Internet communications cannot be guaranteed to be timely, > > secure, error or virus-free. The sender does not accept liability for any > > errors or omissions. > > > > _______________________________________________ > > Carbon-dev mailing list > > [email protected] > > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > > > > > -- > Thanks & Regards, > Prabath > > http://blog.facilelogin.com > http://RampartFAQ.com > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
