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
