On Tue, Feb 17, 2015 at 10:55 AM, KasunG Gajasinghe <[email protected]> wrote:
> > 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. > We will look into this if its possible. > > 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 < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Sun, Jul 6, 2014 at 3:12 PM, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> Hi Kishanthan, >>>>> >>>>> >>>>> On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah < >>>>> [email protected]> 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 >>>>>> [email protected] >>>>>> 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 > > > -- 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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
