Hi Paul, On Wed, Feb 23, 2011 at 4:12 PM, Paul Fremantle <[email protected]> wrote: > Anjana > You are not making a fair comparison here: Why aren't you comparing adding a > nice UI to DSS (new coding) with adding a nice UI to the generic security > controls that apply to all services (also new coding)? > In other words, why are you so keen to add improvements to DSS and not keen > to make those same improvements generic and apply to all services? > Please work on adding this to the overall security controls and not just to > DSS. If that really isn't possible to do in a nice way, then we can look > again.
Yeah I agree having the generic functionality is the ideal solution. Maybe you misunderstood my initial intentions, I was simply trying to figure out the best way to implement this type of functionality, either in some existing functionality, a product specific feature, or implementing a new generic feature. This thread is suppose to come to a conclusion on that. Cheers, Anjana. > Paul > On 23 February 2011 07:10, 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. >> >> 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 > > > > -- > 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. > -- 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
