Hi Johann,

After looking through the new implementation of the
*SecurityDeploymentIntercepter.java
*file in the latest GIT source code[1] , I could find that this
"allowRoles" parameter related implementation has been removed. Entire
implementation of the *applySecurityParameters(AxisService service,
SecurityScenario secScenario)* method has been removed and that method is
blank. What is the reason for this?

@Sohani: This is the reason that this parameter is not working in the
latest 4.9.0 ESB pack.

[1]
https://github.com/wso2/carbon-identity/blob/master/components/security/org.wso2.carbon.security.mgt/src/main/java/org/wso2/carbon/security/deployment/SecurityDeploymentInterceptor.java


Thanks,
Chanaka

On Mon, Apr 6, 2015 at 11:35 AM, Chanaka Fernando <chana...@wso2.com> wrote:

> Hi KasunG,
>
> I have checked on the source code of the previous implementation and
> according to that, when applying security through Management console and
> through "allowRoles" service parameter, it executes the same code on the
> Security side (please see below).
>
> *SecurityConfigAdmin.java (Executes when applying through Management
> Console)*
>
>             if (userGroups != null) {
>                 for (String value : userGroups) {
>                     AuthorizationManager acAdmin =
> realm.getAuthorizationManager();
>
>                         acAdmin.authorizeRole(value,
> serviceGroupId+"/"+service.getName(),
>
> UserCoreConstants.INVOKE_SERVICE_PERMISSION);
>                 }
>             }
>
>
>
> *SecurityDeploymentIntercepter.java (Executes when applying through
> "allowRoles" parameter)*
>
>             Parameter allowRolesParameter =
> service.getParameter("allowRoles");
>
>             if(allowRolesParameter!= null &&
> allowRolesParameter.getValue() != null){
>
>                 AuthorizationManager manager =
> userRealm.getAuthorizationManager();
>                 String resourceName = serviceGroupId + "/" + serviceName;
>                 String[] roles =
> manager.getAllowedRolesForResource(resourceName,
>
> UserCoreConstants.INVOKE_SERVICE_PERMISSION);
>                 if(roles != null){
>                     for (String role : roles) {
>                         manager.clearRoleAuthorization(role, resourceName,
>
> UserCoreConstants.INVOKE_SERVICE_PERMISSION);
>                     }
>                 }
>
>                 String value = (String) allowRolesParameter.getValue();
>                 String[] allowRoles = value.split(",") ;
>                 if(allowRoles != null){
>                     for(String role : allowRoles){
>
> userRealm.getAuthorizationManager().authorizeRole(role, resourceName,
>
> UserCoreConstants.INVOKE_SERVICE_PERMISSION);
>                     }
>                 }
>             }
>
>
> Since this is a service level parameter, we can use this for all axis2
> services. If that is the case, we can go with this parameter instead of
> having properties at registry resource level. WDYT?
>
> @Sohani: I will look in the 4.9.0 related issue when using this parameter.
>
>
> Thanks,
> Chanaka
>
>
> On Thu, Apr 2, 2015 at 5:25 PM, Chanaka Fernando <chana...@wso2.com>
> wrote:
>
>> Hi Sohani,
>>
>> Please see my comments inline.
>>
>> AFAIK when we deploy a proxy which has allowRoles parameter, the
>> 'UM_PERMISSION ' table is getting updated and an entry is created with that
>> ID in the UM_ROLE_PERMISSION table. This works fine with ESB 4.8.1 but with
>> ESB 4.9.0 the UM_PERMISSION table is not getting updated. Therefore, I
>> think we need to modify the existing deployer to handle this task as we
>> have discussed during the last meeting. Correct me if I am wrong.
>>
>> -- I have also checked in the code and this "allowRoles" property do the
>> same operation in the JDBCAuthorizationManager class when we add the user
>> roles from the management console. So it should work as expected. But
>> KasunG's point is that this is a kind of a quick fix and this may not work
>> for axis2 services.
>>
>> When concerning the new suggestion of including the user role information
>> as a registry property of the registry resource, how can we handle updating
>> the user role information in the database since we don't have the proxy
>> information at the time we create the policy file? Can someone please
>> advise on the way to proceed with this.
>>
>> -- Here you don't need to add this information to the database from DevS
>> side. At the deployment time, deployer will check the user role from the
>> resource properties and add that to the relevant database using the
>> JDBCAuthorizationManager class.
>>
>> Shall we have a meeting to discuss about this further? WDYT?
>>
>> +1 for a meeting.
>>
>>
>> Thanks,
>> Chanaka
>>
>>
>>
>>
>> On Thu, Apr 2, 2015 at 3:32 PM, Sohani Weerasinghe <soh...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> AFAIK when we deploy a proxy which has allowRoles parameter, the
>>> 'UM_PERMISSION ' table is getting updated and an entry is created with that
>>> ID in the UM_ROLE_PERMISSION table. This works fine with ESB 4.8.1 but with
>>> ESB 4.9.0 the UM_PERMISSION table is not getting updated. Therefore, I
>>> think we need to modify the existing deployer to handle this task as we
>>> have discussed during the last meeting. Correct me if I am wrong.
>>>
>>> When concerning the new suggestion of including the user role
>>> information as a registry property of the registry resource, how can we
>>> handle updating the user role information in the database since we don't
>>> have the proxy information at the time we create the policy file? Can
>>> someone please advise on the way to proceed with this.
>>>
>>> Shall we have a meeting to discuss about this further? WDYT?
>>>
>>> Thanks,
>>> Sohani
>>>
>>>
>>> Sohani Weerasinghe
>>> Software Engineer
>>> WSO2, Inc: http://wso2.com
>>>
>>> Mobile  : +94 716439774
>>> Blog     :http://christinetechtips.blogspot.com/
>>> Twitter  : https://twitter.com/sohanichristine
>>>
>>> On Tue, Mar 31, 2015 at 5:11 PM, KasunG Gajasinghe <kas...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Tue, Mar 31, 2015 at 4:59 PM, Isuru Udana <isu...@wso2.com> wrote:
>>>>
>>>>> Hi KasunG,
>>>>>
>>>>> On Tue, Mar 31, 2015 at 4:32 PM, KasunG Gajasinghe <kas...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Two questions -
>>>>>>
>>>>>> 1. Why do we need a separate axis2 deployer to handle just user roles?
>>>>>>
>>>>> We were thinking about modifying existing deployers (proxy deployer
>>>>> etc) to call the relevant component in the security side.
>>>>>
>>>>
>>>> To add the policy to a service, you can also use an AxisObserver. With
>>>> this, you won't need to patch the deployers. You can re-use the existing
>>>> code in DeploymentInterceptor class in carbon core component on applying
>>>> policies to runtime AxisService object.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 2. Isn't it much cleaner if we keep the list of user roles as a
>>>>>> registry property of the registry resource that contains the policy? 
>>>>>> Then,
>>>>>> this won't depend on the service type, and the security configuration 
>>>>>> will
>>>>>> be located in a single place. I believe allowRoles was provided as a 
>>>>>> quick
>>>>>> fix for a support ticket.
>>>>>>
>>>>> This is a very good suggestion. Let's consider this option as well.
>>>>>
>>>>
>>>> Sounds good!
>>>>
>>>>
>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 3:53 PM, Sohani Weerasinghe <soh...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Meeting notes is as follows
>>>>>>>
>>>>>>> Participants: Jasintha, Susinda, Awanthika, Chanaka, IsuruU, Johann,
>>>>>>> Godwin, Dulindra, Sohani
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>> From the Developer Studio perspective, currently we are implementing
>>>>>>> the security policy as a registry resource and as per the discussion 
>>>>>>> had we
>>>>>>> will use the parameter 'allowRoles' to define the relevant user roles. 
>>>>>>> This
>>>>>>> will be a service level parameter and the roles can be obtained by
>>>>>>> connecting to the server.
>>>>>>>
>>>>>>> This parameter is already available with ESB and this needs to be
>>>>>>> facilitated by DSS and Axis2.
>>>>>>>
>>>>>>> From the Servers (ESB, DSS and AS) a deployer needs to be
>>>>>>> implemented to handle user roles at the run time
>>>>>>>
>>>>>>> Please add points to this if I have missed anything.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sohani
>>>>>>>
>>>>>>> Sohani Weerasinghe
>>>>>>> Software Engineer
>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>
>>>>>>> Mobile  : +94 716439774
>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>
>>>>>>> On Thu, Mar 26, 2015 at 3:35 PM, Sohani Weerasinghe <soh...@wso2.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi Chanaka,
>>>>>>>>
>>>>>>>> Thanks for the explanation and as per the offline discussion we
>>>>>>>> had,  let's have a meeting on next week so that we can discuss and 
>>>>>>>> finalize
>>>>>>>> the things.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sohani
>>>>>>>>
>>>>>>>> Sohani Weerasinghe
>>>>>>>> Software Engineer
>>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>>
>>>>>>>> Mobile  : +94 716439774
>>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>>
>>>>>>>> On Thu, Mar 26, 2015 at 3:26 PM, Chanaka Fernando <
>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Sohani,
>>>>>>>>>
>>>>>>>>> I got your idea. But what I meant was that this does not give any
>>>>>>>>> additional security. BTW, I am not against the registry based 
>>>>>>>>> approach  :)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Chanaka
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 26, 2015 at 3:05 PM, Sohani Weerasinghe <
>>>>>>>>> soh...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> @Chanaka : I just considered the fact that if we specify it as a
>>>>>>>>>> parameter then that information will be visible. That is why thought 
>>>>>>>>>> of
>>>>>>>>>> saving it as a registry resource would be better. But if we can 
>>>>>>>>>> continue
>>>>>>>>>> with the parameter then we'll continue the testing with that.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Sohani
>>>>>>>>>>
>>>>>>>>>> Sohani Weerasinghe
>>>>>>>>>> Software Engineer
>>>>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>>>>
>>>>>>>>>> Mobile  : +94 716439774
>>>>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 26, 2015 at 3:02 PM, Chanaka Fernando <
>>>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Sohani,
>>>>>>>>>>>
>>>>>>>>>>> What is the additional security you get from having that
>>>>>>>>>>> parameter in registry?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Chanaka
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 26, 2015 at 2:55 PM, Sohani Weerasinghe <
>>>>>>>>>>> soh...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Chanaka,
>>>>>>>>>>>>
>>>>>>>>>>>> Please find my comments inline
>>>>>>>>>>>>
>>>>>>>>>>>> Sohani Weerasinghe
>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>>>>>>
>>>>>>>>>>>> Mobile  : +94 716439774
>>>>>>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 26, 2015 at 2:18 PM, Chanaka Fernando <
>>>>>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Godwin,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please see my comments inline.
>>>>>>>>>>>>>
>>>>>>>>>>>>> AFAIK, in old model (file base persistence) roles are not
>>>>>>>>>>>>> persisting in meta file and it use AuthorizationManager
>>>>>>>>>>>>> (JDBCAuthorizationManager) for persistence, We use same model for 
>>>>>>>>>>>>> current
>>>>>>>>>>>>> implementation as well and roles are not persisting in registry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem with that approach is we need to include this
>>>>>>>>>>>>> information within the CAR file. Otherwise, it is not self 
>>>>>>>>>>>>> contained. We
>>>>>>>>>>>>> need to have this user role information within the CAR file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> @Sohani: If we can make sure all the security related
>>>>>>>>>>>>> scenarios (which requires user related information) are working 
>>>>>>>>>>>>> properly
>>>>>>>>>>>>> with the <parameter name="allowRoles">admin</parameter>, then we 
>>>>>>>>>>>>> can use
>>>>>>>>>>>>> this parameter instead of a separate registry resource.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When considering the security perspective isn't it better to
>>>>>>>>>>>> specify user roles information as a registry resource rather than 
>>>>>>>>>>>> use as a
>>>>>>>>>>>> parameter? WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Chanaka
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 25, 2015 at 11:46 PM, Godwin Amila Shrimal <
>>>>>>>>>>>>> god...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Sohani,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AFAIK, in old model (file base persistence) roles are not
>>>>>>>>>>>>>> persisting in meta file and it use AuthorizationManager
>>>>>>>>>>>>>> (JDBCAuthorizationManager) for persistence, We use same model 
>>>>>>>>>>>>>> for current
>>>>>>>>>>>>>> implementation as well and roles are not persisting in registry.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Godwin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Mar 25, 2015 at 11:23 AM, Sohani Weerasinghe <
>>>>>>>>>>>>>> soh...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Chanaka/Godwin,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In order to further implement this feature I really
>>>>>>>>>>>>>>> appreciate your input on the below concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. When considering the security perspective, it seems we
>>>>>>>>>>>>>>> have two options to specify user roles config either as a 
>>>>>>>>>>>>>>> registry resource
>>>>>>>>>>>>>>> or using the parameter 'allowRoles' in the proxy configuration. 
>>>>>>>>>>>>>>> IMO
>>>>>>>>>>>>>>> implement it as a registry resource would be better when 
>>>>>>>>>>>>>>> considering the
>>>>>>>>>>>>>>> security perspective. WDYT?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, if we are to implement it as a registry resource then
>>>>>>>>>>>>>>> the content of the resource will be <parameter
>>>>>>>>>>>>>>> name="allowRoles">admin</parameter>.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Chanaka: Can we have a parameter in the proxy config to
>>>>>>>>>>>>>>> define the registry resource for the user roles as we define 
>>>>>>>>>>>>>>> the security
>>>>>>>>>>>>>>> policy (eg: <policy key="conf:repository/policy.xml"/> ) ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Godwin : If user roles is going to be implemented as a
>>>>>>>>>>>>>>> registry resource, will there be a predefined registry location 
>>>>>>>>>>>>>>> to save it
>>>>>>>>>>>>>>> ?  If so can you please state it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Really appreciate your response on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Sohani
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sohani Weerasinghe
>>>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mobile  : +94 716439774
>>>>>>>>>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>>>>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 3:52 PM, Sohani Weerasinghe <
>>>>>>>>>>>>>>> soh...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Chanaka/Godwin,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Can you please provide an input on the below concerns to
>>>>>>>>>>>>>>>> further carry out the implementation from DevS side.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1.When considering the usability aspect, I think it's
>>>>>>>>>>>>>>>> better if we can create a registry resource for user roles at 
>>>>>>>>>>>>>>>> the time of
>>>>>>>>>>>>>>>> creating the policy using the Security Editor Form by getting 
>>>>>>>>>>>>>>>> the User
>>>>>>>>>>>>>>>> Roles values from the user rather than asking user to create a 
>>>>>>>>>>>>>>>> new registry
>>>>>>>>>>>>>>>> resource for User Roles.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Godwin: can you please state the required registry path to
>>>>>>>>>>>>>>>> deploy the User Roles configs?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. If the User Roles config saves as a registry resource,
>>>>>>>>>>>>>>>> how this can be utilize by the proxy service? Will there be a 
>>>>>>>>>>>>>>>> property in
>>>>>>>>>>>>>>>> the proxy service so that we can point the User Role config as 
>>>>>>>>>>>>>>>> pointing the
>>>>>>>>>>>>>>>> policy file.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. If we are deploying the policy and User Role configs via
>>>>>>>>>>>>>>>> CAPP, in a case where multiple policy files deploying in the 
>>>>>>>>>>>>>>>> same registry
>>>>>>>>>>>>>>>> location, in order to match the User Role config with the 
>>>>>>>>>>>>>>>> relevant policy
>>>>>>>>>>>>>>>> file, how can we identify the matching User Role config and 
>>>>>>>>>>>>>>>> the policy? Can
>>>>>>>>>>>>>>>> we have the same resource name for the policy and the User 
>>>>>>>>>>>>>>>> Role configs?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Chanaka: can you please confirm points 2 and 3?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Sohani
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sohani Weerasinghe
>>>>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>>>>> WSO2, Inc: http://wso2.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mobile  : +94 716439774
>>>>>>>>>>>>>>>> Blog     :http://christinetechtips.blogspot.com/
>>>>>>>>>>>>>>>> Twitter  : https://twitter.com/sohanichristine
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 3:42 PM, Chanaka Fernando <
>>>>>>>>>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Godwin,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That would be good.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Chanaka
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 3:40 PM, Godwin Amila Shrimal <
>>>>>>>>>>>>>>>>> god...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Chanaka,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It'll finish within this week.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>> Godwin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 3:35 PM, Chanaka Fernando <
>>>>>>>>>>>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Godwin,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When will you finish the offsite dev service?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Chanaka
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 3:30 PM, Godwin Amila Shrimal <
>>>>>>>>>>>>>>>>>>> god...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Chanaka,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We have basically completed the registry base
>>>>>>>>>>>>>>>>>>>> implementation in security mgt component and need to do 
>>>>>>>>>>>>>>>>>>>> code refactoring
>>>>>>>>>>>>>>>>>>>> and more testing. I tested basic scenarios with 
>>>>>>>>>>>>>>>>>>>> STS-service and it worked
>>>>>>>>>>>>>>>>>>>> ok. Currently I am in an offsite DevService and planning 
>>>>>>>>>>>>>>>>>>>> to do remaining
>>>>>>>>>>>>>>>>>>>> refactoring and testing after this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>> Godwin
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 24, 2015 at 2:00 PM, Chanaka Fernando <
>>>>>>>>>>>>>>>>>>>> chana...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am writing this mail to take the discussions related
>>>>>>>>>>>>>>>>>>>>> to $subject in to a single place. With the ESB 4.9.0 
>>>>>>>>>>>>>>>>>>>>> release, we are
>>>>>>>>>>>>>>>>>>>>> removing the UI capability of applying security policies 
>>>>>>>>>>>>>>>>>>>>> from the
>>>>>>>>>>>>>>>>>>>>> management console. Going forward, users can only apply 
>>>>>>>>>>>>>>>>>>>>> security policies
>>>>>>>>>>>>>>>>>>>>> to ESB proxy services using developer studio. Even though 
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> functionality is already available in the Developer 
>>>>>>>>>>>>>>>>>>>>> Studio, it has some
>>>>>>>>>>>>>>>>>>>>> edge cases when we use that approach. One such limitation 
>>>>>>>>>>>>>>>>>>>>> is that there is
>>>>>>>>>>>>>>>>>>>>> no place to select the users/roles in the developer 
>>>>>>>>>>>>>>>>>>>>> studio when applying
>>>>>>>>>>>>>>>>>>>>> the security policy. Currently, this information is 
>>>>>>>>>>>>>>>>>>>>> stored in meta files
>>>>>>>>>>>>>>>>>>>>> and with the 4.9.0 version, service meta files are 
>>>>>>>>>>>>>>>>>>>>> removed. Plan is to
>>>>>>>>>>>>>>>>>>>>> store this information in registry and access from their. 
>>>>>>>>>>>>>>>>>>>>> From the
>>>>>>>>>>>>>>>>>>>>> Developer Studio also, it will create the registry file 
>>>>>>>>>>>>>>>>>>>>> when applying
>>>>>>>>>>>>>>>>>>>>> security policies.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This would be a necessary feature for ESB 4.9.0
>>>>>>>>>>>>>>>>>>>>> release since this will effect the entire security 
>>>>>>>>>>>>>>>>>>>>> applying process going
>>>>>>>>>>>>>>>>>>>>> forward.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Godwin: Please add if I have missed anything and give
>>>>>>>>>>>>>>>>>>>>> us some update on the status from the security side.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Sohani/DevS team: Please give us some update on this
>>>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Chanaka
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Chanaka Fernando
>>>>>>>>>>>>>>>>>>>>> Technical Lead
>>>>>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> mobile: +94 773337238
>>>>>>>>>>>>>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>>>>>>>>>>>>>> LinkedIn:
>>>>>>>>>>>>>>>>>>>>> http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>>>>>>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>>>>>>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> *Godwin Amila Shrimal*
>>>>>>>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> mobile: *+94772264165*
>>>>>>>>>>>>>>>>>>>> linkedin: *http://lnkd.in/KUum6D
>>>>>>>>>>>>>>>>>>>> <http://lnkd.in/KUum6D>*
>>>>>>>>>>>>>>>>>>>> twitter: https://twitter.com/godwinamila
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Chanaka Fernando
>>>>>>>>>>>>>>>>>>> Technical Lead
>>>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> mobile: +94 773337238
>>>>>>>>>>>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>>>>>>>>>>>> LinkedIn:
>>>>>>>>>>>>>>>>>>> http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>>>>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>>>>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> *Godwin Amila Shrimal*
>>>>>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> mobile: *+94772264165*
>>>>>>>>>>>>>>>>>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>>>>>>>>>>>>>>>>>> twitter: https://twitter.com/godwinamila
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Chanaka Fernando
>>>>>>>>>>>>>>>>> Technical Lead
>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> mobile: +94 773337238
>>>>>>>>>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>>>>>>>>>> LinkedIn:
>>>>>>>>>>>>>>>>> http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Godwin Amila Shrimal*
>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> mobile: *+94772264165*
>>>>>>>>>>>>>> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
>>>>>>>>>>>>>> twitter: https://twitter.com/godwinamila
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Chanaka Fernando
>>>>>>>>>>>>> Technical Lead
>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>>
>>>>>>>>>>>>> mobile: +94 773337238
>>>>>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>>>>>> LinkedIn:
>>>>>>>>>>>>> http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> Chanaka Fernando
>>>>>>>>>>> Technical Lead
>>>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>
>>>>>>>>>>> mobile: +94 773337238
>>>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Chanaka Fernando
>>>>>>>>> Technical Lead
>>>>>>>>> WSO2, Inc.; http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> mobile: +94 773337238
>>>>>>>>> Blog : http://soatutorials.blogspot.com
>>>>>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>>>>> Wordpress:http://chanakaudaya.wordpress.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Isuru Udana*
>>>>> Senior
>>>>> *Software Engineer*
>>>>> WSO2 Inc.; http://wso2.com
>>>>> email: isu...@wso2.com cell: +94 77 3791887
>>>>> blog: http://mytecheye.blogspot.com/
>>>>> twitter: http://twitter.com/isudana
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> --
>> Chanaka Fernando
>> Technical Lead
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 773337238
>> Blog : http://soatutorials.blogspot.com
>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>> Twitter:https://twitter.com/chanakaudaya
>> Wordpress:http://chanakaudaya.wordpress.com
>>
>>
>>
>>
>
>
> --
> --
> Chanaka Fernando
> Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
> Wordpress:http://chanakaudaya.wordpress.com
>
>
>
>


-- 
--
Chanaka Fernando
Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 773337238
Blog : http://soatutorials.blogspot.com
LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
Twitter:https://twitter.com/chanakaudaya
Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to