[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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
