Hi Chanaka,
It seems it's better to use the scenarioId for the default policies. By
using the scenarioId, we will be able to enforce the disable of unsecured
transports as well.
Will we have to keep this in the service configuration as a service-level
parameter? If so, I suppose we should probabl
Hi All,
I have started implementing end to end flow of the discussed approach to
apply security for ESB proxy service. I have been able to apply the
security to an ESB proxy service using the policy file (stored in registry)
and with the "allowRoles" service parameter defined in the proxy service
Hi Jasintha,
Creating the policy file in either file system or registry is absolutely
fine and we can use the common policy wizard for that.
However, from bpel project perspective, we need a way to embed such created
policy file into a services.xml file since we need to be able to define
addition
On Wed, Apr 8, 2015 at 2:13 PM, Jasintha Dasanayake
wrote:
> Hi all
>
> From the tooling perspective it is not nice to have different user
> experience for applying security for various project and IMO it should be
> same for all project types .
>
> As we identified there should be only two step
Hi all
>From the tooling perspective it is not nice to have different user
experience for applying security for various project and IMO it should be
same for all project types .
As we identified there should be only two steps for applying all types of
projects
1 - create the policy (user can ke
Hi Jasintha,
Is it a hard requirement to create the policy as a registry resource. I
would prefer to have it in the file system within service.xml file. For
example you can refer to the following bpel project.
https://github.com/wso2/product-bps/tree/master/modules/samples/product/src/main/resour
With this approach, there is no need hard requirement to use registry to
store policies. We are using the native ws policy support provided by each
service artifact.
So,
1. For proxy services, the policy could be stored in registry or in file
system as a local-entry. A proxy-level configura
Hi Nandika
At the moment, create policy is independent usecase that will be created as
registry resource, let say , user will create a policy as a registry
resource and that policy file will be referred in the BPS project using a
policy key (which is the location of the policy).
Thanks and Regard
Hi Johann,
There is an additional parameter "scenarioID" which is getting populated
when applying security for proxy service through UI in the old model. How
can we specify this parameter with the new approach? Is it possible to
remove this parameter from the service level?
Thanks,
Chanaka
On
We can add the parameter to the service.xml that can be packaged with bpel
package. We will update the deployment logic to handle that addition. From
dev studio perspective, we would need support for creating the policy file
from the bpel project itself and some improvements to the deploy.xml
edito
Meeting notes is as follows:
Participants: Jasintha, Nandika, Johann, Chanaka, IsuruU, KasunG, Godwin,
RajithV, Sohani
Notes:
Each product needs to provide a service parameter to define user roles, and
the creation of axis2 object including the policy and user roles needs to
be handle by each pr
Hi All,
Please note that I have arranged a meeting tomorrow at 11am to 12pm to
discuss about this further.
Thanks,
Sohani
Sohani Weerasinghe
Software Engineer
WSO2, Inc: http://wso2.com
Mobile : +94 716439774
Blog :http://christinetechtips.blogspot.com/
Twitter : https://twitter.com/sohan
Sohani Weerasinghe
Software Engineer
WSO2, Inc: http://wso2.com
Mobile : +94 716439774
Blog :http://christinetechtips.blogspot.com/
Twitter : https://twitter.com/sohanichristine
On Tue, Apr 7, 2015 at 11:19 AM, Nandika Jayawardana
wrote:
> Yes. Lets have a meeting and get at least one per
Yes. Lets have a meeting and get at least one person from all the affected
teams.
Regards
Nandika
On Tue, Apr 7, 2015 at 11:08 AM, Chanaka Fernando wrote:
> Hi Sohani,
>
> Shall we arrange a meeting to discuss this and finalize the approach?
> Looks like we have several approaches but still we
Hi Sohani,
Shall we arrange a meeting to discuss this and finalize the approach? Looks
like we have several approaches but still we have not agreed on a proper
solution.
Thanks,
Chanaka
On Tue, Apr 7, 2015 at 10:12 AM, Nandika Jayawardana
wrote:
> In BPS, we have to pack the policy file within
In BPS, we have to pack the policy file within the bpel project itself and
refer to it in the deploy.xml. We are going to have to update the
deployment code as we are creating the axis service objects dynamically.
Regards
Nandika
On Tue, Apr 7, 2015 at 10:04 AM, Chanaka Fernando wrote:
> Hi Joh
Hi Johann/KasunG/Kishanthan,
What would be the way forward to support this feature? We can have the
Developer Studio story completed if we use the "allowRoles" parameter with
the *SecurityDeploymentIntercepter *class updating the DB. If we are going
with the registry resource property approach, we
Hi Kasun/Kishanthan,
Any idea why this was removed ? I thought security-mgt is maintained by IS
team. But looks like others are also working on this component.
On Mon, Apr 6, 2015 at 12:05 PM, Sohani Weerasinghe wrote:
> @Chanaka: Thanks for investigating on this issue.
>
> Sohani Weerasinghe
>
@Chanaka: Thanks for investigating on this issue.
Sohani Weerasinghe
Software Engineer
WSO2, Inc: http://wso2.com
Mobile : +94 716439774
Blog :http://christinetechtips.blogspot.com/
Twitter : https://twitter.com/sohanichristine
On Mon, Apr 6, 2015 at 12:02 PM, Chanaka Fernando wrote:
> H
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 servi
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 w
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 n
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
th
Hi,
On Tue, Mar 31, 2015 at 4:59 PM, Isuru Udana wrote:
> Hi KasunG,
>
> On Tue, Mar 31, 2015 at 4:32 PM, KasunG Gajasinghe
> wrote:
>
>> Hi,
>>
>> Two questions -
>>
>> 1. Why do we need a separate axis2 deployer to handle just user roles?
>>
> We were thinking about modifying existing deploye
Hi KasunG,
On Tue, Mar 31, 2015 at 4:32 PM, KasunG Gajasinghe 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
Hi Johann,
KasunG's suggestion looks good. Rather than writing different deployers for
different service types, we can change the security component to read the
user roles from the registry resource property.
WDYT?
Thanks,
Chanaka
On Tue, Mar 31, 2015 at 4:32 PM, KasunG Gajasinghe wrote:
> H
Hi,
Two questions -
1. Why do we need a separate axis2 deployer to handle just user roles?
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 configurat
Additional notes:
The proxy config would be as follows:
http://ws.apache.org/ns/synapse";>
*admin*
Thanks,
Sohani
Sohani Weerasinghe
Software Engineer
WSO2, Inc: http://wso2.com
Mobile : +94 716439774
Blog :http://christinetechtips.blogspot.com/
Twit
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 paramete
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://christinet
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 wrote:
> @Chanaka : I just considered the fact that if we specify it as
@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 We
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 wrote:
> Hi Chanaka,
>
> Please find my comments inline
>
> Sohani Weerasinghe
> Software Engineer
> WSO2, Inc: http://wso2.com
>
> Mob
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 wrote:
> Hi Godw
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.
T
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,
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 prox
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 E
Hi Godwin,
That would be good.
Thanks,
Chanaka
On Tue, Mar 24, 2015 at 3:40 PM, Godwin Amila Shrimal
wrote:
> Hi Chanaka,
>
> It'll finish within this week.
>
>
> Thanks
> Godwin
>
>
> On Tue, Mar 24, 2015 at 3:35 PM, Chanaka Fernando
> wrote:
>
>> Hi Godwin,
>>
>> When will you finish the of
Hi Chanaka,
It'll finish within this week.
Thanks
Godwin
On Tue, Mar 24, 2015 at 3:35 PM, Chanaka Fernando 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
> wrote:
>
>> Hi Chanaka,
>>
>> We
Hi Godwin,
When will you finish the offsite dev service?
Thanks,
Chanaka
On Tue, Mar 24, 2015 at 3:30 PM, Godwin Amila Shrimal
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 t
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 test
@KasunG: Yes, only few scenarios need user roles. I'll test that with
relevant scenarios.
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
Not all security scenarios require the roles. For example, the Sign-Only
security scenarios only requires the keystores. Better verify the
allowRoles parameter for all the scenario that do require it though.
On Tue, Mar 24, 2015 at 2:31 PM, Sohani Weerasinghe wrote:
> Hi Chanaka,
>
> I have imp
Hi Chanaka,
I have implemented creating security policy files via Developer Studio and
user role implementation hasn't completed yet since I am waiting for IS
team's input on this. I have discussed this issue @architecture "Implementing
User Roles configurations for security policies with Develope
Hi Susinda,
That would be great if we can get this done by using this parameter. But we
need to check whether there are any other meta information needed for other
security mechanisms.
Thanks,
Chanaka
On Tue, Mar 24, 2015 at 2:13 PM, Susinda Perera wrote:
> Hi Chanaka
>
> On Tue, Mar 24, 2015
Hi Chanaka
On Tue, Mar 24, 2015 at 2:00 PM, Chanaka Fernando 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.
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 usin
48 matches
Mail list logo
