On Wed, Feb 23, 2011 at 5:38 PM, Amila Suriarachchi <am...@wso2.com> wrote:
> > > On Wed, Feb 23, 2011 at 4:50 PM, Prabath Siriwardana <prab...@wso2.com>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. > +1 Thanks & regards, -Prabath > > thanks, > Amila. > > >> Thanks & regards, >> -Prabath >> >> >> >> On Wed, Feb 23, 2011 at 4:16 PM, Paul Fremantle <p...@wso2.com> 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 <am...@wso2.com> wrote: >> >> >> >> >> >> On Wed, Feb 23, 2011 at 11:46 AM, Anjana Fernando <anj...@wso2.com> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> On Wed, Feb 23, 2011 at 11:09 AM, Amila Suriarachchi <am...@wso2.com> >> >>> 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 <anj...@wso2.com >> > >> >>> >> wrote: >> >>> >>> >> >>> >>> On Wed, Feb 23, 2011 at 9:30 AM, Srinath Perera <srin...@wso2.com >> > >> >>> >>> wrote: >> >>> >>> > Others == IS guys , just FYI >> >>> >>> >> >>> >>> Yep OK. >> >>> >>> >> >>> >>> Cheers, >> >>> >>> Anjana. >> >>> >>> >> >>> >>> > >> >>> >>> > On Wed, Feb 23, 2011 at 9:27 AM, Anjana Fernando < >> anj...@wso2.com> >> >>> >>> > wrote: >> >>> >>> >> Hi, >> >>> >>> >> >> >>> >>> >> On Wed, Feb 23, 2011 at 9:21 AM, Srinath Perera < >> srin...@wso2.com> >> >>> >>> >> 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 >> >>> >>> >>> <anj...@wso2.com> >> >>> >>> >>> 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 >> >>> >>> >>>> Carbon-dev@wso2.org >> >>> >>> >>>> 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 >> >>> >>> Carbon-dev@wso2.org >> >>> >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>> >> >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Carbon-dev mailing list >> >>> >> Carbon-dev@wso2.org >> >>> >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>> >> >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Carbon-dev mailing list >> >>> > Carbon-dev@wso2.org >> >>> > 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 >> >> Carbon-dev@wso2.org >> >> 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 >> > p...@wso2.com >> > >> > 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 >> > Carbon-dev@wso2.org >> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> > >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> _______________________________________________ >> Carbon-dev mailing list >> Carbon-dev@wso2.org >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > > -- Thanks & Regards, Prabath http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
