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