There's a parameter called allowRoles that can be used to enforce roles. It could contain a comma separated roles list. But, I believe it would be much cleaner if the roles can also be included in the RampartConfig of the policy.
ESB can go ahead with this approach. Security wizard already resides in carbon-identity component. On Tue, Feb 17, 2015 at 10:42 AM, Kishanthan Thangarajah < kishant...@wso2.com> wrote: > OK, lets go ahead with this. The initial plan is to write this for STS > only so that IS can own this. But If ESB also need this, where are we going > to maintain this? > > On Mon, Feb 16, 2015 at 11:53 AM, Johann Nallathamby <joh...@wso2.com> > wrote: > >> [Adding Godwin to the thread] >> >> IS team has already started working on this targeting the IS 5.1.0 >> release on Git based on carbon-kernel 4.3.0. >> >> Following are items we will be doing. >> >> 1. We will continue using the security wizard to apply STS policies and >> persist it to registry. >> >> 2. Previously the security policies as well as metadata were persisted in >> filesystem for axis2 services. Now we will be persisting them both in >> registry. >> In ESB the security policies only were stored in registry, so we will >> also try to reuse the same logic/location to store the security policies. >> >> 3. Recently we found that ESB also has a problem after removing the >> security wizard. In this new approach although security policies are >> applied in dev studio and persisted in registry we haven't thought about >> the role based access control which you get when doing through the security >> wizard. This got stored in the metafile. I was under the impression that >> this was also decided to be removed with these new changes. But looks like >> they still need it. So once we do this change they also will be able to use >> it. >> >> If you have any concerns please raise them now. >> >> Thanks. >> >> On Mon, Jul 7, 2014 at 3:15 PM, Kishanthan Thangarajah < >> kishant...@wso2.com> wrote: >> >>> >>> >>> >>> On Sun, Jul 6, 2014 at 3:12 PM, Johann Nallathamby <joh...@wso2.com> >>> wrote: >>> >>>> Hi Kishanthan, >>>> >>>> >>>> On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah < >>>> kishant...@wso2.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We recently had a meeting on $subject. Our current story for CApp >>>>> (Carbon Application) development approach is broken when including >>>>> application of QoS for services. This was mainly due to the issues we >>>>> faced >>>>> with, >>>>> >>>>> - the file-based metadata persistence layer for services. >>>>> - the possibility to change/apply QoS via mgt console. >>>>> - clustering and deployment synchronization. >>>>> >>>>> To fix these, as the first step, we have removed the file based >>>>> persistence layer from platform. This layer was mainly used to persist QoS >>>>> related settings of the axis2services. This can be replaced by using >>>>> services.xml file for each service. All types of axis2services (other >>>>> than >>>>> proxy-services) has support for services.xml currently. For proxy >>>>> services, >>>>> the application of some QoS (Ex: security) can be defined inline by >>>>> referring the relevant policies from registry. >>>>> >>>>> We need a meeting to discuss about the following next steps. >>>>> - How this will affect ESB (proxy-services) and how to fix those. >>>>> - Removing the current way of applying QoS via mgt console and >>>>> providing a different approach, which will not be part of the CApp >>>>> development process. >>>>> >>>> >>>> This will have serious impact on STS functionality of IS. STS is a >>>> specialised axis2 service, deployed from an OSGi bundle and shared across >>>> all tenants. The security policy used to secure the STS is within the scope >>>> of a tenant and is deployed as a service metafile like any other service. >>>> STS is unsecured by default. Tenant admins would secure the STS with >>>> preferred policy. >>>> >>>> Two reason why the above approach would not work for IS, >>>> >>>> 1. Securing STS is a admin functionality in my opinion. It is not a >>>> development time aspect. This may be not the case for other services. >>>> >>>> 2. Since STS is a shared service editing services.xml won't work. >>>> >>>> If we go with this new approach in platform, we need to do the >>>> following from IS side. >>>> >>>> 1. We need to continue using the security wizard UI to apply policies >>>> and modify the backend service to persist policy in either registry or >>>> Identity DB. >>>> >>>> 2. We need to modify the Security Deployment Interceptor which reads >>>> the security policy from filesystem, to read it from registry or database. >>>> >>> >>> Yes, this would be the option here. You can also use the same approach >>> like how proxy services keep policy references for applied security >>> scenarios with registry. >>> >>> >>>> >>>> @Sagara/KasunG >>>> How is AS team planning to handle this. Are you going to deprecate >>>> usage of security wizard UI and leave it to development time? Or are you >>>> having any other approach in mind? >>>> >>>> Thanks, >>>> Johann. >>>> >>>> >>>>> Thanks, >>>>> Kishanthan. >>>>> >>>>> -- >>>>> *Kishanthan Thangarajah* >>>>> Senior Software Engineer, >>>>> Platform Technologies Team, >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - +94773426635 >>>>> Blog - *http://kishanthan.wordpress.com >>>>> <http://kishanthan.wordpress.com>* >>>>> Twitter - *http://twitter.com/kishanthan >>>>> <http://twitter.com/kishanthan>* >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> d...@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>>> Integration Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >>> >>> -- >>> *Kishanthan Thangarajah* >>> Senior Software Engineer, >>> Platform Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com >>> <http://kishanthan.wordpress.com>* >>> Twitter - *http://twitter.com/kishanthan >>> <http://twitter.com/kishanthan>* >>> >> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Associate Technical Lead & Product Lead of WSO2 Identity Server >> Integration Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. email: kasung AT spamfree wso2.com linked-in: http://lk.linkedin.com/in/gajasinghe blog: http://kasunbg.org
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
