On Wed, Feb 23, 2011 at 10:28 AM, Dimuthu Leelarathne <[email protected]>wrote:
> Hi Anjana, > > We have this feature already implemented. This is how you control access to > operations in services.xml. > > <operation name="getWSDL"> > <parameter name="AuthorizationAction" > locked="false">/permission/admin/xyz/uid</parameter> > </operation> > > > And one more thing. In Carbon framework we do NOT say this role can access > this resource. > In Carbon framework we say any role with this permission can access this > resource. > 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. 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
