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... 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
