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