On Wed, Feb 23, 2011 at 12:40 PM, Anjana Fernando <[email protected]> wrote:
> Hi, > > On Wed, Feb 23, 2011 at 12:28 PM, Amila Suriarachchi <[email protected]> > wrote: > > > > you can use carbon service dash board to add operation level parameters. > > Oh I see, it's simply setting the necessary Axis2 parameters, also > well, this maybe a tradeoff between that functionality being generic > and the usability, because as I see, setting a simple option in the > DSS UI is far easier for the user than he going to service dashboard > and adding a specific operation level parameter. > yes you can think of that way as well. But having all the security related stuff in on place improve the usability in platform wise. For a example if a user wants to sign and encrypt to secure a message are you going to add that to the DSS to improve the usability? If you think like that you may end up having a set products which does the same thing in product specific way. thanks, Amila. > > Cheers, > Anjana. > > > 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 > > > > > > > > -- > 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
