You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Ruchith Fernando <ru...@gmail.com> on 2006/03/22 04:15:07 UTC
Re: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Hi,
I downloaded Synapse [1] and I couldn't find any of the security
related mediators in it.
Thanks,
Ruchith
Ref:
[1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> Sanjiva:
>
> The X-Broker codebase was contributed to seed Synapse. The feature
> functions listed here are those which were available in the commercial
> version of the X-Broker and are now being built into Synapse.
>
> I think this a perfectly valid response on the mailing list and hope it
> addresses your concerns.
>
> Mukund Balasubramanian
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: synapse-dev@ws.apache.org
> Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Um, r u talking about Synapse or your product? Please be sure you are
> clear what you're talking about .. its not appropriate to use ASF
> mailing lists to advertise your products.
>
> Sanjiva.
>
> On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > Hi,
> >
> > The mediation framework, which is Synapse, can take care of the use
> cases
> > that you mentioned. It's a proxy-based model and acts as a policy
> enforcer,
> > which can be configured and enforced using the mediators. If you want
> more
> > information you can also post your queries at
> > http://www.infravio.com/community/ for our existing broker
> architecture on
> > which the mediators are based.
> >
> > Just to give you a background we have the following mediators:
> >
> > ConsumerIdentificationMediator: This mediator will identify the client
> who
> > sent the request. The ways to identify the clients are:
> > IP
> > IP-Range
> > WS-SEC Token
> > HTTP Token
> > Certificates
> > LDAP
> >
> > SecurityMediators:
> > VerifySignatureMediator: This mediator will verify signature if
> required.
> > SignMediator: This mediator will sign the request if required
> > DecryptMediator: This will decrypt the message
> > EncryptMediator: This will encrypt the response if configured
> >
> > RoutingMediators:
> > FailoverMediator :
> > Failover is the act of switching to a secondary service in case the
> primary
> > service fails.
> > Hence, logically, we can configure failover only when we have 2 or
> more
> > endpoints providing similar
> > services.
> > The failover process can be initiated on timeout and or faults.
> > In case of 'failover on faults' the FailoverMediator keeps switching
> to
> > secondary services,
> > until all the secondary services are tried or one of them returns a
> > successful result.
> > In case of failover based routing on timeout is active, the
> participating
> > end-points would be given
> > timeout values and the connection would be forced to close and a fault
> would
> > be returned if no
> > response arrives within that many milliseconds and then 'failover on
> fault'
> > logic kicks in.
> >
> > LoadbalancingMediator:
> > Loadbalancing is the act of distributing the load, the requests
> for a
> > particular service across
> > various service endpoints.
> > In case a provider has more than one endpoint that provides the same
> > service, he would like the
> > load of requests being made to be distributed across them.
> >
> > The strategy being supported now is round robin i.e. requests would be
> sent
> > to the various participating
> > services in a round-robin, one after another fashion.
> > In case the service that was invoked fails to respond, the mediator
> switches
> > to the next one in the line.
> > Its a mere pass, hence the next request will get directed to the one
> which
> > was supposed to handle it if
> > the previous service didn't fail.
> >
> > DeprecationMediator:
> > This mediator validated if a service has been deprecated
> (date wise) and
> > depending on it routes it.
> >
> > SLAMediator: Depending on the ConsumerIdentification mediator a
> priority
> > is selected for the clients and based on it the
> > request is queued.
> >
> > ManagementMediator: This mediator will gather management related
> information
> > and notify management reporting application, currently we are planning
> to
> > implement it using JMX.
> >
> > LoggingMediator: Will gather logging information and log it to
> appropriate
> > log4j appender
> >
> >
> > Thanks
> > Soumadeep
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > >
> > >
> > > Hi Ruchith,
> > > Thank you for your reply.
> > > If I use the security module, is it possible that we use different
> > security
> > > policies for different client, i.e., the security policy is a
> contract
> > > between the service and a specific client or group of clients. What
> I want
> > > to do includes two kind of things: first kind is to receive a
> SOAPEnvelope
> > > which contains client information in the header part. According to
> the
> > > client information, I apply predefined security policy to the
> SOAPEnvelope
> > > (this may include add username token, signature, and/or encryption
> based
> > on
> > > the client info), and send the SOAPEnvelope to the destination EPR.
> >
> > I think this is a scenario where you have an intermediary service
> > which will be the client to the actual service that the original
> > client wants to invoke.
> > IMHO this certainly can be supported with the existing axis2 security
> > module.
> > Basically when the client send the request to the intermediary service
> > it can configure the how the request should be configured
> > dynamically to invoke the secured service. You can use the
> > InflowConfiguration and OutflowConfiguration objects to configure [1].
> >
> > > The other scenario I want to add addressing information to the
> message
> > > before client send out the SOAPEnvelope. The addressing information
> may be
> > > retrieved from database according to the client info.
> > > Can I still use the security module and addressing module to realize
> my
> > > tasks?
> >
> > Axis2 comes with the addressing module ... you can configure things
> > like wsa:To and wsa:Action using the axis2 client API.
> >
> > BTW your scenarios sound a lot like scenarios that can be supported
> > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > synapse-dev list as well)
> >
> > Thanks,
> > Ruchith
> >
> > Ref:
> > [1]
> >
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> curi
> > ty/src/org/apache/axis2/security/handler/config/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On 3/22/06, Soumadeep <so...@infravio.com> wrote:
>
> Hi Ruchith,
>
> That's a good observation. The features that were listed have not been
> committed as yet because we are still in the process of doing so. We will
> keep you posted.
Mediators are one unique entities that are going to grow exponentially as
Synapse grows. Paul, as the release manager, has put on the M2 todo list
what we should expect on M2 release. Security and RM is must.
As this is a ASF project, if you guys are writing mediators, please be kind
enough to *write a descriptive note* to this mailing list before committing
any code, otherwise it will be like the thread on SynapseObject, where there
are other proven alternative technologies exist than SynapesObject itself.
When i read your response, you have mentioned some mediators that ain't
exist in M1 or M2 candidate. So IMHO we should try to stick to what we have
now and what we have agreed to do on.
As Synapse started from scratch with no string attached, let it be a good
code base to other developers to develop.
Thank you
Saminda
Thanks
> Soumadeep
>
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Wednesday, March 22, 2006 8:45 AM
> To: synapse-dev@ws.apache.org
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Hi,
>
> I downloaded Synapse [1] and I couldn't find any of the security
> related mediators in it.
>
> Thanks,
> Ruchith
>
> Ref:
> [1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
>
> On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> > Sanjiva:
> >
> > The X-Broker codebase was contributed to seed Synapse. The feature
> > functions listed here are those which were available in the commercial
> > version of the X-Broker and are now being built into Synapse.
> >
> > I think this a perfectly valid response on the mailing list and hope it
> > addresses your concerns.
> >
> > Mukund Balasubramanian
> >
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> > Sent: Tuesday, March 21, 2006 6:55 PM
> > To: synapse-dev@ws.apache.org
> > Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> > Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> > properties:crypto.properties
> >
> > Um, r u talking about Synapse or your product? Please be sure you are
> > clear what you're talking about .. its not appropriate to use ASF
> > mailing lists to advertise your products.
> >
> > Sanjiva.
> >
> > On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > > Hi,
> > >
> > > The mediation framework, which is Synapse, can take care of the use
> > cases
> > > that you mentioned. It's a proxy-based model and acts as a policy
> > enforcer,
> > > which can be configured and enforced using the mediators. If you want
> > more
> > > information you can also post your queries at
> > > http://www.infravio.com/community/ for our existing broker
> > architecture on
> > > which the mediators are based.
> > >
> > > Just to give you a background we have the following mediators:
> > >
> > > ConsumerIdentificationMediator: This mediator will identify the client
> > who
> > > sent the request. The ways to identify the clients are:
> > > IP
> > > IP-Range
> > > WS-SEC Token
> > > HTTP Token
> > > Certificates
> > > LDAP
> > >
> > > SecurityMediators:
> > > VerifySignatureMediator: This mediator will verify signature if
> > required.
> > > SignMediator: This mediator will sign the request if required
> > > DecryptMediator: This will decrypt the message
> > > EncryptMediator: This will encrypt the response if configured
> > >
> > > RoutingMediators:
> > > FailoverMediator :
> > > Failover is the act of switching to a secondary service in case the
> > primary
> > > service fails.
> > > Hence, logically, we can configure failover only when we have 2 or
> > more
> > > endpoints providing similar
> > > services.
> > > The failover process can be initiated on timeout and or faults.
> > > In case of 'failover on faults' the FailoverMediator keeps switching
> > to
> > > secondary services,
> > > until all the secondary services are tried or one of them returns a
> > > successful result.
> > > In case of failover based routing on timeout is active, the
> > participating
> > > end-points would be given
> > > timeout values and the connection would be forced to close and a fault
> > would
> > > be returned if no
> > > response arrives within that many milliseconds and then 'failover on
> > fault'
> > > logic kicks in.
> > >
> > > LoadbalancingMediator:
> > > Loadbalancing is the act of distributing the load, the requests
> > for a
> > > particular service across
> > > various service endpoints.
> > > In case a provider has more than one endpoint that provides the same
> > > service, he would like the
> > > load of requests being made to be distributed across them.
> > >
> > > The strategy being supported now is round robin i.e. requests would be
> > sent
> > > to the various participating
> > > services in a round-robin, one after another fashion.
> > > In case the service that was invoked fails to respond, the mediator
> > switches
> > > to the next one in the line.
> > > Its a mere pass, hence the next request will get directed to the one
> > which
> > > was supposed to handle it if
> > > the previous service didn't fail.
> > >
> > > DeprecationMediator:
> > > This mediator validated if a service has been deprecated
> > (date wise) and
> > > depending on it routes it.
> > >
> > > SLAMediator: Depending on the ConsumerIdentification mediator a
> > priority
> > > is selected for the clients and based on it the
> > > request is queued.
> > >
> > > ManagementMediator: This mediator will gather management related
> > information
> > > and notify management reporting application, currently we are planning
> > to
> > > implement it using JMX.
> > >
> > > LoggingMediator: Will gather logging information and log it to
> > appropriate
> > > log4j appender
> > >
> > >
> > > Thanks
> > > Soumadeep
> > > -----Original Message-----
> > > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Sent: Tuesday, March 21, 2006 9:02 PM
> > > To: Xinjun Chen
> > > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> > >
> > > Hi Xinjun,
> > >
> > > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > > >
> > > >
> > > > Hi Ruchith,
> > > > Thank you for your reply.
> > > > If I use the security module, is it possible that we use different
> > > security
> > > > policies for different client, i.e., the security policy is a
> > contract
> > > > between the service and a specific client or group of clients. What
> > I want
> > > > to do includes two kind of things: first kind is to receive a
> > SOAPEnvelope
> > > > which contains client information in the header part. According to
> > the
> > > > client information, I apply predefined security policy to the
> > SOAPEnvelope
> > > > (this may include add username token, signature, and/or encryption
> > based
> > > on
> > > > the client info), and send the SOAPEnvelope to the destination EPR.
> > >
> > > I think this is a scenario where you have an intermediary service
> > > which will be the client to the actual service that the original
> > > client wants to invoke.
> > > IMHO this certainly can be supported with the existing axis2 security
> > > module.
> > > Basically when the client send the request to the intermediary service
> > > it can configure the how the request should be configured
> > > dynamically to invoke the secured service. You can use the
> > > InflowConfiguration and OutflowConfiguration objects to configure [1].
> > >
> > > > The other scenario I want to add addressing information to the
> > message
> > > > before client send out the SOAPEnvelope. The addressing information
> > may be
> > > > retrieved from database according to the client info.
> > > > Can I still use the security module and addressing module to realize
> > my
> > > > tasks?
> > >
> > > Axis2 comes with the addressing module ... you can configure things
> > > like wsa:To and wsa:Action using the axis2 client API.
> > >
> > > BTW your scenarios sound a lot like scenarios that can be supported
> > > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > > synapse-dev list as well)
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > Ref:
> > > [1]
> > >
> > https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> > curi
> > > ty/src/org/apache/axis2/security/handler/config/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
RE: [Synapse]RE: CryptoFactory:Cannotloadproperties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Sure Sanjiva :) , and putting it in the scratch is a good idea at least
people can comment on a concept and on acceptance we can put it in the main
code base.
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Wednesday, March 22, 2006 2:21 PM
To: synapse-dev@ws.apache.org
Cc: Ruchith Fernando
Subject: RE: [Synapse]RE:
CryptoFactory:Cannotloadproperties:crypto.properties
On Wed, 2006-03-22 at 11:48 +0530, Soumadeep wrote:
> One more thing that I would like to emphasize here is that I do agree that
> all the development should happen in the repo, but from a realistic stand
> point as you may agree one can't keep writing a line of code and keep
> committing it but surely the scratch area should be fine.
Come on Soumadeep you know I didn't mean that every line should be
committed. In fact there are times when I go days without committing
changes because I'm not happy with some stuff. However, the diff is
there's no other place where the code is committed in a shared repo; I
may keep it on my machine for however long but from day 0 its meant to
go to ASF and I keep committing when I feel its good and ready to
commit.
The only reason to commit to the scratch area instead of the main tree
is if the stuff is really "scratch" .. otherwise if the code is an
improvement to the main direction of the project it belongs in the main
tree.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory:
Cannotloadproperties:crypto.properties
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-03-22 at 11:48 +0530, Soumadeep wrote:
> One more thing that I would like to emphasize here is that I do agree that
> all the development should happen in the repo, but from a realistic stand
> point as you may agree one can't keep writing a line of code and keep
> committing it but surely the scratch area should be fine.
Come on Soumadeep you know I didn't mean that every line should be
committed. In fact there are times when I go days without committing
changes because I'm not happy with some stuff. However, the diff is
there's no other place where the code is committed in a shared repo; I
may keep it on my machine for however long but from day 0 its meant to
go to ASF and I keep committing when I feel its good and ready to
commit.
The only reason to commit to the scratch area instead of the main tree
is if the stuff is really "scratch" .. otherwise if the code is an
improvement to the main direction of the project it belongs in the main
tree.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannotloadproperties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Sanjiva,
Please see my comments inline
Best regards
Soumadeep
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Wednesday, March 22, 2006 11:18 AM
To: synapse-dev@ws.apache.org
Cc: Ruchith Fernando
Subject: RE: [Synapse]RE: CryptoFactory:
Cannotloadproperties:crypto.properties
On Wed, 2006-03-22 at 09:43 +0530, Soumadeep wrote:
> Sanjiva,
>
> 1) First of all let me emphasize that Mukund's statement and my response
to
> Ruchith are no way related.
OK.
> 2) We work on the mediators and do a primary test before we commit it to
the
> ASF repository.
That is not a good model for development in ASF long term; ASF is about
open development as well, not just about releasing software under the
Apache license. It is a viable model for bootstrap, but now that we have
bootstrapped, we must do all the work here.
[Soumadeep] Yes, I completely agree and that's why I added these points in
my earlier email
2) We work on the mediators and do a primary test before we commit it to the
ASF repository.
3) And whatever that we proposed (like Mukund's management related code
base or SynapseObject) are in the scratch already
4) The reason some of the mediators that we came up with didn't make it to
the repo yet is because of issues pertaining to data sharing between
mediators, and you are aware of the long thread about SynapseObject per se.
One more thing that I would like to emphasize here is that I do agree that
all the development should happen in the repo, but from a realistic stand
point as you may agree one can't keep writing a line of code and keep
committing it but surely the scratch area should be fine. And I reiterate
that we have no intention of putting mediators in one go but put a generic
structure to it and then let the community develop it. One can argue
endlessly on this but then just to put it in the right perspective we have
developed these features and have gone through several use cases with many
customers in a rigorous manner. Hence, apart from just the code we are also
sharing the knowledgebase so that we don't start re-inventing the wheel
again but maybe add to it. On a lighter note maybe add some good tiers to it
:)
Of course *it is perfectly viable* for Infravio or anyone else to build
their own add-ons and ship them in their products.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot
loadproperties:crypto.properties
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-03-22 at 09:43 +0530, Soumadeep wrote:
> Sanjiva,
>
> 1) First of all let me emphasize that Mukund's statement and my response to
> Ruchith are no way related.
OK.
> 2) We work on the mediators and do a primary test before we commit it to the
> ASF repository.
That is not a good model for development in ASF long term; ASF is about
open development as well, not just about releasing software under the
Apache license. It is a viable model for bootstrap, but now that we have
bootstrapped, we must do all the work here.
Of course *it is perfectly viable* for Infravio or anyone else to build
their own add-ons and ship them in their products.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot loadproperties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Sanjiva,
1) First of all let me emphasize that Mukund's statement and my response to
Ruchith are no way related.
2) We work on the mediators and do a primary test before we commit it to the
ASF repository.
3) And what ever that we proposed (like Mukund's management related code
base or SynapseObject) are in the scratch already
4) The reason some of the mediators that we came up with didn't make it to
the repo yet is because of issues pertaining to data sharing between
mediators, and
you are aware of the long thread about SynapseObject per se.
I hope this addresses your concerns.
Best regards
Soumadeep
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Wednesday, March 22, 2006 9:17 AM
To: Soumadeep
Cc: Ruchith Fernando; synapse-dev@ws.apache.org
Subject: RE: [Synapse]RE: CryptoFactory: Cannot
loadproperties:crypto.properties
(Removed wss4j-dev from the discussion.)
This statement below is inconsistent with Mukund's that the code was
already contributed. If this code is not already contributed then is it
new code? If so can you do the work in the ASF repo itself? (You can do
it in scratch if that's preferred because we're still changing the base
platform.)
I of course understand people will build additional mediators on their
own. My own company will likely do the same.
However, if those mediators are to be part of the core of Synapse then
they must be done on this mailing list - you can't just do them
elsewhere and contribute them without going thru a software grant
process. That process is needed for legal clarity.
Sanjiva.
On Wed, 2006-03-22 at 08:57 +0530, Soumadeep wrote:
> Hi Ruchith,
>
> That's a good observation. The features that were listed have not been
> committed as yet because we are still in the process of doing so. We will
> keep you posted.
>
> Thanks
> Soumadeep
>
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Wednesday, March 22, 2006 8:45 AM
> To: synapse-dev@ws.apache.org
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Hi,
>
> I downloaded Synapse [1] and I couldn't find any of the security
> related mediators in it.
>
> Thanks,
> Ruchith
>
> Ref:
> [1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
>
> On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> > Sanjiva:
> >
> > The X-Broker codebase was contributed to seed Synapse. The feature
> > functions listed here are those which were available in the commercial
> > version of the X-Broker and are now being built into Synapse.
> >
> > I think this a perfectly valid response on the mailing list and hope it
> > addresses your concerns.
> >
> > Mukund Balasubramanian
> >
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> > Sent: Tuesday, March 21, 2006 6:55 PM
> > To: synapse-dev@ws.apache.org
> > Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> > Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> > properties:crypto.properties
> >
> > Um, r u talking about Synapse or your product? Please be sure you are
> > clear what you're talking about .. its not appropriate to use ASF
> > mailing lists to advertise your products.
> >
> > Sanjiva.
> >
> > On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > > Hi,
> > >
> > > The mediation framework, which is Synapse, can take care of the use
> > cases
> > > that you mentioned. It's a proxy-based model and acts as a policy
> > enforcer,
> > > which can be configured and enforced using the mediators. If you want
> > more
> > > information you can also post your queries at
> > > http://www.infravio.com/community/ for our existing broker
> > architecture on
> > > which the mediators are based.
> > >
> > > Just to give you a background we have the following mediators:
> > >
> > > ConsumerIdentificationMediator: This mediator will identify the client
> > who
> > > sent the request. The ways to identify the clients are:
> > > IP
> > > IP-Range
> > > WS-SEC Token
> > > HTTP Token
> > > Certificates
> > > LDAP
> > >
> > > SecurityMediators:
> > > VerifySignatureMediator: This mediator will verify signature if
> > required.
> > > SignMediator: This mediator will sign the request if required
> > > DecryptMediator: This will decrypt the message
> > > EncryptMediator: This will encrypt the response if configured
> > >
> > > RoutingMediators:
> > > FailoverMediator :
> > > Failover is the act of switching to a secondary service in case the
> > primary
> > > service fails.
> > > Hence, logically, we can configure failover only when we have 2 or
> > more
> > > endpoints providing similar
> > > services.
> > > The failover process can be initiated on timeout and or faults.
> > > In case of 'failover on faults' the FailoverMediator keeps switching
> > to
> > > secondary services,
> > > until all the secondary services are tried or one of them returns a
> > > successful result.
> > > In case of failover based routing on timeout is active, the
> > participating
> > > end-points would be given
> > > timeout values and the connection would be forced to close and a fault
> > would
> > > be returned if no
> > > response arrives within that many milliseconds and then 'failover on
> > fault'
> > > logic kicks in.
> > >
> > > LoadbalancingMediator:
> > > Loadbalancing is the act of distributing the load, the requests
> > for a
> > > particular service across
> > > various service endpoints.
> > > In case a provider has more than one endpoint that provides the same
> > > service, he would like the
> > > load of requests being made to be distributed across them.
> > >
> > > The strategy being supported now is round robin i.e. requests would be
> > sent
> > > to the various participating
> > > services in a round-robin, one after another fashion.
> > > In case the service that was invoked fails to respond, the mediator
> > switches
> > > to the next one in the line.
> > > Its a mere pass, hence the next request will get directed to the one
> > which
> > > was supposed to handle it if
> > > the previous service didn't fail.
> > >
> > > DeprecationMediator:
> > > This mediator validated if a service has been deprecated
> > (date wise) and
> > > depending on it routes it.
> > >
> > > SLAMediator: Depending on the ConsumerIdentification mediator a
> > priority
> > > is selected for the clients and based on it the
> > > request is queued.
> > >
> > > ManagementMediator: This mediator will gather management related
> > information
> > > and notify management reporting application, currently we are planning
> > to
> > > implement it using JMX.
> > >
> > > LoggingMediator: Will gather logging information and log it to
> > appropriate
> > > log4j appender
> > >
> > >
> > > Thanks
> > > Soumadeep
> > > -----Original Message-----
> > > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Sent: Tuesday, March 21, 2006 9:02 PM
> > > To: Xinjun Chen
> > > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> > >
> > > Hi Xinjun,
> > >
> > > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > > >
> > > >
> > > > Hi Ruchith,
> > > > Thank you for your reply.
> > > > If I use the security module, is it possible that we use different
> > > security
> > > > policies for different client, i.e., the security policy is a
> > contract
> > > > between the service and a specific client or group of clients. What
> > I want
> > > > to do includes two kind of things: first kind is to receive a
> > SOAPEnvelope
> > > > which contains client information in the header part. According to
> > the
> > > > client information, I apply predefined security policy to the
> > SOAPEnvelope
> > > > (this may include add username token, signature, and/or encryption
> > based
> > > on
> > > > the client info), and send the SOAPEnvelope to the destination EPR.
> > >
> > > I think this is a scenario where you have an intermediary service
> > > which will be the client to the actual service that the original
> > > client wants to invoke.
> > > IMHO this certainly can be supported with the existing axis2 security
> > > module.
> > > Basically when the client send the request to the intermediary service
> > > it can configure the how the request should be configured
> > > dynamically to invoke the secured service. You can use the
> > > InflowConfiguration and OutflowConfiguration objects to configure [1].
> > >
> > > > The other scenario I want to add addressing information to the
> > message
> > > > before client send out the SOAPEnvelope. The addressing information
> > may be
> > > > retrieved from database according to the client info.
> > > > Can I still use the security module and addressing module to realize
> > my
> > > > tasks?
> > >
> > > Axis2 comes with the addressing module ... you can configure things
> > > like wsa:To and wsa:Action using the axis2 client API.
> > >
> > > BTW your scenarios sound a lot like scenarios that can be supported
> > > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > > synapse-dev list as well)
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > Ref:
> > > [1]
> > >
> > https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> > curi
> > > ty/src/org/apache/axis2/security/handler/config/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot load
properties:crypto.properties
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
(Removed wss4j-dev from the discussion.)
This statement below is inconsistent with Mukund's that the code was
already contributed. If this code is not already contributed then is it
new code? If so can you do the work in the ASF repo itself? (You can do
it in scratch if that's preferred because we're still changing the base
platform.)
I of course understand people will build additional mediators on their
own. My own company will likely do the same.
However, if those mediators are to be part of the core of Synapse then
they must be done on this mailing list - you can't just do them
elsewhere and contribute them without going thru a software grant
process. That process is needed for legal clarity.
Sanjiva.
On Wed, 2006-03-22 at 08:57 +0530, Soumadeep wrote:
> Hi Ruchith,
>
> That's a good observation. The features that were listed have not been
> committed as yet because we are still in the process of doing so. We will
> keep you posted.
>
> Thanks
> Soumadeep
>
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Wednesday, March 22, 2006 8:45 AM
> To: synapse-dev@ws.apache.org
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Hi,
>
> I downloaded Synapse [1] and I couldn't find any of the security
> related mediators in it.
>
> Thanks,
> Ruchith
>
> Ref:
> [1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
>
> On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> > Sanjiva:
> >
> > The X-Broker codebase was contributed to seed Synapse. The feature
> > functions listed here are those which were available in the commercial
> > version of the X-Broker and are now being built into Synapse.
> >
> > I think this a perfectly valid response on the mailing list and hope it
> > addresses your concerns.
> >
> > Mukund Balasubramanian
> >
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> > Sent: Tuesday, March 21, 2006 6:55 PM
> > To: synapse-dev@ws.apache.org
> > Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> > Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> > properties:crypto.properties
> >
> > Um, r u talking about Synapse or your product? Please be sure you are
> > clear what you're talking about .. its not appropriate to use ASF
> > mailing lists to advertise your products.
> >
> > Sanjiva.
> >
> > On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > > Hi,
> > >
> > > The mediation framework, which is Synapse, can take care of the use
> > cases
> > > that you mentioned. It's a proxy-based model and acts as a policy
> > enforcer,
> > > which can be configured and enforced using the mediators. If you want
> > more
> > > information you can also post your queries at
> > > http://www.infravio.com/community/ for our existing broker
> > architecture on
> > > which the mediators are based.
> > >
> > > Just to give you a background we have the following mediators:
> > >
> > > ConsumerIdentificationMediator: This mediator will identify the client
> > who
> > > sent the request. The ways to identify the clients are:
> > > IP
> > > IP-Range
> > > WS-SEC Token
> > > HTTP Token
> > > Certificates
> > > LDAP
> > >
> > > SecurityMediators:
> > > VerifySignatureMediator: This mediator will verify signature if
> > required.
> > > SignMediator: This mediator will sign the request if required
> > > DecryptMediator: This will decrypt the message
> > > EncryptMediator: This will encrypt the response if configured
> > >
> > > RoutingMediators:
> > > FailoverMediator :
> > > Failover is the act of switching to a secondary service in case the
> > primary
> > > service fails.
> > > Hence, logically, we can configure failover only when we have 2 or
> > more
> > > endpoints providing similar
> > > services.
> > > The failover process can be initiated on timeout and or faults.
> > > In case of 'failover on faults' the FailoverMediator keeps switching
> > to
> > > secondary services,
> > > until all the secondary services are tried or one of them returns a
> > > successful result.
> > > In case of failover based routing on timeout is active, the
> > participating
> > > end-points would be given
> > > timeout values and the connection would be forced to close and a fault
> > would
> > > be returned if no
> > > response arrives within that many milliseconds and then 'failover on
> > fault'
> > > logic kicks in.
> > >
> > > LoadbalancingMediator:
> > > Loadbalancing is the act of distributing the load, the requests
> > for a
> > > particular service across
> > > various service endpoints.
> > > In case a provider has more than one endpoint that provides the same
> > > service, he would like the
> > > load of requests being made to be distributed across them.
> > >
> > > The strategy being supported now is round robin i.e. requests would be
> > sent
> > > to the various participating
> > > services in a round-robin, one after another fashion.
> > > In case the service that was invoked fails to respond, the mediator
> > switches
> > > to the next one in the line.
> > > Its a mere pass, hence the next request will get directed to the one
> > which
> > > was supposed to handle it if
> > > the previous service didn't fail.
> > >
> > > DeprecationMediator:
> > > This mediator validated if a service has been deprecated
> > (date wise) and
> > > depending on it routes it.
> > >
> > > SLAMediator: Depending on the ConsumerIdentification mediator a
> > priority
> > > is selected for the clients and based on it the
> > > request is queued.
> > >
> > > ManagementMediator: This mediator will gather management related
> > information
> > > and notify management reporting application, currently we are planning
> > to
> > > implement it using JMX.
> > >
> > > LoggingMediator: Will gather logging information and log it to
> > appropriate
> > > log4j appender
> > >
> > >
> > > Thanks
> > > Soumadeep
> > > -----Original Message-----
> > > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Sent: Tuesday, March 21, 2006 9:02 PM
> > > To: Xinjun Chen
> > > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> > >
> > > Hi Xinjun,
> > >
> > > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > > >
> > > >
> > > > Hi Ruchith,
> > > > Thank you for your reply.
> > > > If I use the security module, is it possible that we use different
> > > security
> > > > policies for different client, i.e., the security policy is a
> > contract
> > > > between the service and a specific client or group of clients. What
> > I want
> > > > to do includes two kind of things: first kind is to receive a
> > SOAPEnvelope
> > > > which contains client information in the header part. According to
> > the
> > > > client information, I apply predefined security policy to the
> > SOAPEnvelope
> > > > (this may include add username token, signature, and/or encryption
> > based
> > > on
> > > > the client info), and send the SOAPEnvelope to the destination EPR.
> > >
> > > I think this is a scenario where you have an intermediary service
> > > which will be the client to the actual service that the original
> > > client wants to invoke.
> > > IMHO this certainly can be supported with the existing axis2 security
> > > module.
> > > Basically when the client send the request to the intermediary service
> > > it can configure the how the request should be configured
> > > dynamically to invoke the secured service. You can use the
> > > InflowConfiguration and OutflowConfiguration objects to configure [1].
> > >
> > > > The other scenario I want to add addressing information to the
> > message
> > > > before client send out the SOAPEnvelope. The addressing information
> > may be
> > > > retrieved from database according to the client info.
> > > > Can I still use the security module and addressing module to realize
> > my
> > > > tasks?
> > >
> > > Axis2 comes with the addressing module ... you can configure things
> > > like wsa:To and wsa:Action using the axis2 client API.
> > >
> > > BTW your scenarios sound a lot like scenarios that can be supported
> > > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > > synapse-dev list as well)
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > Ref:
> > > [1]
> > >
> > https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> > curi
> > > ty/src/org/apache/axis2/security/handler/config/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
WSS4J in WebSphere enviroment
Posted by ma...@fsb.se.
Hi
I am trying to get WSS4J to secure a web service that is generated by
the IBM plugin in WSAD(5.1.2). The IBM plugin is based only on Jaxrpc,
no references to Axis. So I am using the WSS4J
jaxrpc(org.apache.ws.security.handler.WSS4JHandler) handler by defining
it as an inbound security handler.
Unfortunate I am not getting it to work. When I generate the same web
service with Axis and specify the Axis WSS4J handler it works like a
charm(both in a Tomcat and a WebSphere server). The parameters for the
Axis and the Jaxrpc handler is as follows:
Axis:
<requestFlow>
<handler
type="java:org.apache.ws.axis.security.WSDoAllReceiver">
<parameter name="passwordCallbackClass"
value="se.fsb.spoe.security.PWCallback"/>
<parameter name="action" value="Signature Encrypt
Timestamp"/>
<parameter name="signaturePropFile"
value="cryptoserver.properties" />
</handler>
</requestFlow>
Jaxrpc:
<init-param id="InitParam_23424352342">
<param-name>passwordCallbackClass</param-name>
<param-value>se.fsb.spoe.security.PWCallback</param-value>
</init-param>
<init-param id="InitParam_23452345232872983">
<param-name>action</param-name>
<param-value>Signature Encrypt Timestamp</param-value>
</init-param>
<init-param id="InitParam_1146546345872984">
<param-name>signaturePropFile</param-name>
<param-value>cryptoserver.properties</param-value>
</init-param>
<init-param id="InitParam_114253563472985">
<param-name>deployment</param-name>
<param-value>server</param-value>
</init-param>
<init-param id="InitParam_114234563456872986">
<param-name>flow</param-name>
<param-value>request-only</param-value>
</init-param>
I have debugged as far as it was possible and its when the
WSSecurityEngine tries to verifies the XML Signature (method
verifyXmlSignature(Element, Crypto, X509Certificate, Vector)) at line
571 (WSS4J version 1.0.0). The following is executed at that line
signatureOk = sig.checkSignatureValue(certs[0]); Where sig is a
org.apache.xml.security.signature.XMLSignature. Unfortunate I can't get
the debugger to find the source code lines when entering the xmlsec so I
can see exactly where the problem occurs. But during the call the
following is written in the server console
"org.apache.xml.security.signature.Reference Verification successful
for URI "#id-1680521892"". This should indicate that the signature is
valid but the checkSignatureValue method returns false which WSS4J then
of course reports as a WSSecurityException.
Has anyone used WSS4J jaxrpc handler successfully in a WebSphere 5.1
enviroment? Anyone that has any ideas on what can be wrong?
As the company I am working for has a simple web service framework build
with jaxrpc handlers (things like authentication, SST etc) I am
recommended to use the WSS4J without Axis. But if I can show that there
are some problems with it I hope that I can use Axis instead. As I need
to state my case on why Axis is needed I would like to find whats
causing this error I am getting.
Thanks,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
WSS4J in WebSphere enviroment
Posted by ma...@fsb.se.
Hi
I am trying to get WSS4J to secure a web service that is generated by
the IBM plugin in WSAD(5.1.2). The IBM plugin is based only on Jaxrpc,
no references to Axis. So I am using the WSS4J
jaxrpc(org.apache.ws.security.handler.WSS4JHandler) handler by defining
it as an inbound security handler.
Unfortunate I am not getting it to work. When I generate the same web
service with Axis and specify the Axis WSS4J handler it works like a
charm(both in a Tomcat and a WebSphere server). The parameters for the
Axis and the Jaxrpc handler is as follows:
Axis:
<requestFlow>
<handler
type="java:org.apache.ws.axis.security.WSDoAllReceiver">
<parameter name="passwordCallbackClass"
value="se.fsb.spoe.security.PWCallback"/>
<parameter name="action" value="Signature Encrypt
Timestamp"/>
<parameter name="signaturePropFile"
value="cryptoserver.properties" />
</handler>
</requestFlow>
Jaxrpc:
<init-param id="InitParam_23424352342">
<param-name>passwordCallbackClass</param-name>
<param-value>se.fsb.spoe.security.PWCallback</param-value>
</init-param>
<init-param id="InitParam_23452345232872983">
<param-name>action</param-name>
<param-value>Signature Encrypt Timestamp</param-value>
</init-param>
<init-param id="InitParam_1146546345872984">
<param-name>signaturePropFile</param-name>
<param-value>cryptoserver.properties</param-value>
</init-param>
<init-param id="InitParam_114253563472985">
<param-name>deployment</param-name>
<param-value>server</param-value>
</init-param>
<init-param id="InitParam_114234563456872986">
<param-name>flow</param-name>
<param-value>request-only</param-value>
</init-param>
I have debugged as far as it was possible and its when the
WSSecurityEngine tries to verifies the XML Signature (method
verifyXmlSignature(Element, Crypto, X509Certificate, Vector)) at line
571 (WSS4J version 1.0.0). The following is executed at that line
signatureOk = sig.checkSignatureValue(certs[0]); Where sig is a
org.apache.xml.security.signature.XMLSignature. Unfortunate I can't get
the debugger to find the source code lines when entering the xmlsec so I
can see exactly where the problem occurs. But during the call the
following is written in the server console
"org.apache.xml.security.signature.Reference Verification successful
for URI "#id-1680521892"". This should indicate that the signature is
valid but the checkSignatureValue method returns false which WSS4J then
of course reports as a WSSecurityException.
Has anyone used WSS4J jaxrpc handler successfully in a WebSphere 5.1
enviroment? Anyone that has any ideas on what can be wrong?
As the company I am working for has a simple web service framework build
with jaxrpc handlers (things like authentication, SST etc) I am
recommended to use the WSS4J without Axis. But if I can show that there
are some problems with it I hope that I can use Axis instead. As I need
to state my case on why Axis is needed I would like to find whats
causing this error I am getting.
Thanks,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Hi Ruchith,
That's a good observation. The features that were listed have not been
committed as yet because we are still in the process of doing so. We will
keep you posted.
Thanks
Soumadeep
-----Original Message-----
From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
Sent: Wednesday, March 22, 2006 8:45 AM
To: synapse-dev@ws.apache.org
Cc: wss4j-dev@ws.apache.org
Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
properties:crypto.properties
Hi,
I downloaded Synapse [1] and I couldn't find any of the security
related mediators in it.
Thanks,
Ruchith
Ref:
[1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> Sanjiva:
>
> The X-Broker codebase was contributed to seed Synapse. The feature
> functions listed here are those which were available in the commercial
> version of the X-Broker and are now being built into Synapse.
>
> I think this a perfectly valid response on the mailing list and hope it
> addresses your concerns.
>
> Mukund Balasubramanian
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: synapse-dev@ws.apache.org
> Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Um, r u talking about Synapse or your product? Please be sure you are
> clear what you're talking about .. its not appropriate to use ASF
> mailing lists to advertise your products.
>
> Sanjiva.
>
> On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > Hi,
> >
> > The mediation framework, which is Synapse, can take care of the use
> cases
> > that you mentioned. It's a proxy-based model and acts as a policy
> enforcer,
> > which can be configured and enforced using the mediators. If you want
> more
> > information you can also post your queries at
> > http://www.infravio.com/community/ for our existing broker
> architecture on
> > which the mediators are based.
> >
> > Just to give you a background we have the following mediators:
> >
> > ConsumerIdentificationMediator: This mediator will identify the client
> who
> > sent the request. The ways to identify the clients are:
> > IP
> > IP-Range
> > WS-SEC Token
> > HTTP Token
> > Certificates
> > LDAP
> >
> > SecurityMediators:
> > VerifySignatureMediator: This mediator will verify signature if
> required.
> > SignMediator: This mediator will sign the request if required
> > DecryptMediator: This will decrypt the message
> > EncryptMediator: This will encrypt the response if configured
> >
> > RoutingMediators:
> > FailoverMediator :
> > Failover is the act of switching to a secondary service in case the
> primary
> > service fails.
> > Hence, logically, we can configure failover only when we have 2 or
> more
> > endpoints providing similar
> > services.
> > The failover process can be initiated on timeout and or faults.
> > In case of 'failover on faults' the FailoverMediator keeps switching
> to
> > secondary services,
> > until all the secondary services are tried or one of them returns a
> > successful result.
> > In case of failover based routing on timeout is active, the
> participating
> > end-points would be given
> > timeout values and the connection would be forced to close and a fault
> would
> > be returned if no
> > response arrives within that many milliseconds and then 'failover on
> fault'
> > logic kicks in.
> >
> > LoadbalancingMediator:
> > Loadbalancing is the act of distributing the load, the requests
> for a
> > particular service across
> > various service endpoints.
> > In case a provider has more than one endpoint that provides the same
> > service, he would like the
> > load of requests being made to be distributed across them.
> >
> > The strategy being supported now is round robin i.e. requests would be
> sent
> > to the various participating
> > services in a round-robin, one after another fashion.
> > In case the service that was invoked fails to respond, the mediator
> switches
> > to the next one in the line.
> > Its a mere pass, hence the next request will get directed to the one
> which
> > was supposed to handle it if
> > the previous service didn't fail.
> >
> > DeprecationMediator:
> > This mediator validated if a service has been deprecated
> (date wise) and
> > depending on it routes it.
> >
> > SLAMediator: Depending on the ConsumerIdentification mediator a
> priority
> > is selected for the clients and based on it the
> > request is queued.
> >
> > ManagementMediator: This mediator will gather management related
> information
> > and notify management reporting application, currently we are planning
> to
> > implement it using JMX.
> >
> > LoggingMediator: Will gather logging information and log it to
> appropriate
> > log4j appender
> >
> >
> > Thanks
> > Soumadeep
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > >
> > >
> > > Hi Ruchith,
> > > Thank you for your reply.
> > > If I use the security module, is it possible that we use different
> > security
> > > policies for different client, i.e., the security policy is a
> contract
> > > between the service and a specific client or group of clients. What
> I want
> > > to do includes two kind of things: first kind is to receive a
> SOAPEnvelope
> > > which contains client information in the header part. According to
> the
> > > client information, I apply predefined security policy to the
> SOAPEnvelope
> > > (this may include add username token, signature, and/or encryption
> based
> > on
> > > the client info), and send the SOAPEnvelope to the destination EPR.
> >
> > I think this is a scenario where you have an intermediary service
> > which will be the client to the actual service that the original
> > client wants to invoke.
> > IMHO this certainly can be supported with the existing axis2 security
> > module.
> > Basically when the client send the request to the intermediary service
> > it can configure the how the request should be configured
> > dynamically to invoke the secured service. You can use the
> > InflowConfiguration and OutflowConfiguration objects to configure [1].
> >
> > > The other scenario I want to add addressing information to the
> message
> > > before client send out the SOAPEnvelope. The addressing information
> may be
> > > retrieved from database according to the client info.
> > > Can I still use the security module and addressing module to realize
> my
> > > tasks?
> >
> > Axis2 comes with the addressing module ... you can configure things
> > like wsa:To and wsa:Action using the axis2 client API.
> >
> > BTW your scenarios sound a lot like scenarios that can be supported
> > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > synapse-dev list as well)
> >
> > Thanks,
> > Ruchith
> >
> > Ref:
> > [1]
> >
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> curi
> > ty/src/org/apache/axis2/security/handler/config/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Hi Ruchith,
That's a good observation. The features that were listed have not been
committed as yet because we are still in the process of doing so. We will
keep you posted.
Thanks
Soumadeep
-----Original Message-----
From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
Sent: Wednesday, March 22, 2006 8:45 AM
To: synapse-dev@ws.apache.org
Cc: wss4j-dev@ws.apache.org
Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
properties:crypto.properties
Hi,
I downloaded Synapse [1] and I couldn't find any of the security
related mediators in it.
Thanks,
Ruchith
Ref:
[1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> Sanjiva:
>
> The X-Broker codebase was contributed to seed Synapse. The feature
> functions listed here are those which were available in the commercial
> version of the X-Broker and are now being built into Synapse.
>
> I think this a perfectly valid response on the mailing list and hope it
> addresses your concerns.
>
> Mukund Balasubramanian
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: synapse-dev@ws.apache.org
> Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Um, r u talking about Synapse or your product? Please be sure you are
> clear what you're talking about .. its not appropriate to use ASF
> mailing lists to advertise your products.
>
> Sanjiva.
>
> On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > Hi,
> >
> > The mediation framework, which is Synapse, can take care of the use
> cases
> > that you mentioned. It's a proxy-based model and acts as a policy
> enforcer,
> > which can be configured and enforced using the mediators. If you want
> more
> > information you can also post your queries at
> > http://www.infravio.com/community/ for our existing broker
> architecture on
> > which the mediators are based.
> >
> > Just to give you a background we have the following mediators:
> >
> > ConsumerIdentificationMediator: This mediator will identify the client
> who
> > sent the request. The ways to identify the clients are:
> > IP
> > IP-Range
> > WS-SEC Token
> > HTTP Token
> > Certificates
> > LDAP
> >
> > SecurityMediators:
> > VerifySignatureMediator: This mediator will verify signature if
> required.
> > SignMediator: This mediator will sign the request if required
> > DecryptMediator: This will decrypt the message
> > EncryptMediator: This will encrypt the response if configured
> >
> > RoutingMediators:
> > FailoverMediator :
> > Failover is the act of switching to a secondary service in case the
> primary
> > service fails.
> > Hence, logically, we can configure failover only when we have 2 or
> more
> > endpoints providing similar
> > services.
> > The failover process can be initiated on timeout and or faults.
> > In case of 'failover on faults' the FailoverMediator keeps switching
> to
> > secondary services,
> > until all the secondary services are tried or one of them returns a
> > successful result.
> > In case of failover based routing on timeout is active, the
> participating
> > end-points would be given
> > timeout values and the connection would be forced to close and a fault
> would
> > be returned if no
> > response arrives within that many milliseconds and then 'failover on
> fault'
> > logic kicks in.
> >
> > LoadbalancingMediator:
> > Loadbalancing is the act of distributing the load, the requests
> for a
> > particular service across
> > various service endpoints.
> > In case a provider has more than one endpoint that provides the same
> > service, he would like the
> > load of requests being made to be distributed across them.
> >
> > The strategy being supported now is round robin i.e. requests would be
> sent
> > to the various participating
> > services in a round-robin, one after another fashion.
> > In case the service that was invoked fails to respond, the mediator
> switches
> > to the next one in the line.
> > Its a mere pass, hence the next request will get directed to the one
> which
> > was supposed to handle it if
> > the previous service didn't fail.
> >
> > DeprecationMediator:
> > This mediator validated if a service has been deprecated
> (date wise) and
> > depending on it routes it.
> >
> > SLAMediator: Depending on the ConsumerIdentification mediator a
> priority
> > is selected for the clients and based on it the
> > request is queued.
> >
> > ManagementMediator: This mediator will gather management related
> information
> > and notify management reporting application, currently we are planning
> to
> > implement it using JMX.
> >
> > LoggingMediator: Will gather logging information and log it to
> appropriate
> > log4j appender
> >
> >
> > Thanks
> > Soumadeep
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > >
> > >
> > > Hi Ruchith,
> > > Thank you for your reply.
> > > If I use the security module, is it possible that we use different
> > security
> > > policies for different client, i.e., the security policy is a
> contract
> > > between the service and a specific client or group of clients. What
> I want
> > > to do includes two kind of things: first kind is to receive a
> SOAPEnvelope
> > > which contains client information in the header part. According to
> the
> > > client information, I apply predefined security policy to the
> SOAPEnvelope
> > > (this may include add username token, signature, and/or encryption
> based
> > on
> > > the client info), and send the SOAPEnvelope to the destination EPR.
> >
> > I think this is a scenario where you have an intermediary service
> > which will be the client to the actual service that the original
> > client wants to invoke.
> > IMHO this certainly can be supported with the existing axis2 security
> > module.
> > Basically when the client send the request to the intermediary service
> > it can configure the how the request should be configured
> > dynamically to invoke the secured service. You can use the
> > InflowConfiguration and OutflowConfiguration objects to configure [1].
> >
> > > The other scenario I want to add addressing information to the
> message
> > > before client send out the SOAPEnvelope. The addressing information
> may be
> > > retrieved from database according to the client info.
> > > Can I still use the security module and addressing module to realize
> my
> > > tasks?
> >
> > Axis2 comes with the addressing module ... you can configure things
> > like wsa:To and wsa:Action using the axis2 client API.
> >
> > BTW your scenarios sound a lot like scenarios that can be supported
> > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > synapse-dev list as well)
> >
> > Thanks,
> > Ruchith
> >
> > Ref:
> > [1]
> >
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> curi
> > ty/src/org/apache/axis2/security/handler/config/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
RE: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Posted by Soumadeep <so...@infravio.com>.
Hi Ruchith,
That's a good observation. The features that were listed have not been
committed as yet because we are still in the process of doing so. We will
keep you posted.
Thanks
Soumadeep
-----Original Message-----
From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
Sent: Wednesday, March 22, 2006 8:45 AM
To: synapse-dev@ws.apache.org
Cc: wss4j-dev@ws.apache.org
Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
properties:crypto.properties
Hi,
I downloaded Synapse [1] and I couldn't find any of the security
related mediators in it.
Thanks,
Ruchith
Ref:
[1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
On 3/22/06, Mukund Balasubramanian <mu...@infravio.com> wrote:
> Sanjiva:
>
> The X-Broker codebase was contributed to seed Synapse. The feature
> functions listed here are those which were available in the commercial
> version of the X-Broker and are now being built into Synapse.
>
> I think this a perfectly valid response on the mailing list and hope it
> addresses your concerns.
>
> Mukund Balasubramanian
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: synapse-dev@ws.apache.org
> Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Um, r u talking about Synapse or your product? Please be sure you are
> clear what you're talking about .. its not appropriate to use ASF
> mailing lists to advertise your products.
>
> Sanjiva.
>
> On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > Hi,
> >
> > The mediation framework, which is Synapse, can take care of the use
> cases
> > that you mentioned. It's a proxy-based model and acts as a policy
> enforcer,
> > which can be configured and enforced using the mediators. If you want
> more
> > information you can also post your queries at
> > http://www.infravio.com/community/ for our existing broker
> architecture on
> > which the mediators are based.
> >
> > Just to give you a background we have the following mediators:
> >
> > ConsumerIdentificationMediator: This mediator will identify the client
> who
> > sent the request. The ways to identify the clients are:
> > IP
> > IP-Range
> > WS-SEC Token
> > HTTP Token
> > Certificates
> > LDAP
> >
> > SecurityMediators:
> > VerifySignatureMediator: This mediator will verify signature if
> required.
> > SignMediator: This mediator will sign the request if required
> > DecryptMediator: This will decrypt the message
> > EncryptMediator: This will encrypt the response if configured
> >
> > RoutingMediators:
> > FailoverMediator :
> > Failover is the act of switching to a secondary service in case the
> primary
> > service fails.
> > Hence, logically, we can configure failover only when we have 2 or
> more
> > endpoints providing similar
> > services.
> > The failover process can be initiated on timeout and or faults.
> > In case of 'failover on faults' the FailoverMediator keeps switching
> to
> > secondary services,
> > until all the secondary services are tried or one of them returns a
> > successful result.
> > In case of failover based routing on timeout is active, the
> participating
> > end-points would be given
> > timeout values and the connection would be forced to close and a fault
> would
> > be returned if no
> > response arrives within that many milliseconds and then 'failover on
> fault'
> > logic kicks in.
> >
> > LoadbalancingMediator:
> > Loadbalancing is the act of distributing the load, the requests
> for a
> > particular service across
> > various service endpoints.
> > In case a provider has more than one endpoint that provides the same
> > service, he would like the
> > load of requests being made to be distributed across them.
> >
> > The strategy being supported now is round robin i.e. requests would be
> sent
> > to the various participating
> > services in a round-robin, one after another fashion.
> > In case the service that was invoked fails to respond, the mediator
> switches
> > to the next one in the line.
> > Its a mere pass, hence the next request will get directed to the one
> which
> > was supposed to handle it if
> > the previous service didn't fail.
> >
> > DeprecationMediator:
> > This mediator validated if a service has been deprecated
> (date wise) and
> > depending on it routes it.
> >
> > SLAMediator: Depending on the ConsumerIdentification mediator a
> priority
> > is selected for the clients and based on it the
> > request is queued.
> >
> > ManagementMediator: This mediator will gather management related
> information
> > and notify management reporting application, currently we are planning
> to
> > implement it using JMX.
> >
> > LoggingMediator: Will gather logging information and log it to
> appropriate
> > log4j appender
> >
> >
> > Thanks
> > Soumadeep
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <xj...@gmail.com> wrote:
> > >
> > >
> > > Hi Ruchith,
> > > Thank you for your reply.
> > > If I use the security module, is it possible that we use different
> > security
> > > policies for different client, i.e., the security policy is a
> contract
> > > between the service and a specific client or group of clients. What
> I want
> > > to do includes two kind of things: first kind is to receive a
> SOAPEnvelope
> > > which contains client information in the header part. According to
> the
> > > client information, I apply predefined security policy to the
> SOAPEnvelope
> > > (this may include add username token, signature, and/or encryption
> based
> > on
> > > the client info), and send the SOAPEnvelope to the destination EPR.
> >
> > I think this is a scenario where you have an intermediary service
> > which will be the client to the actual service that the original
> > client wants to invoke.
> > IMHO this certainly can be supported with the existing axis2 security
> > module.
> > Basically when the client send the request to the intermediary service
> > it can configure the how the request should be configured
> > dynamically to invoke the secured service. You can use the
> > InflowConfiguration and OutflowConfiguration objects to configure [1].
> >
> > > The other scenario I want to add addressing information to the
> message
> > > before client send out the SOAPEnvelope. The addressing information
> may be
> > > retrieved from database according to the client info.
> > > Can I still use the security module and addressing module to realize
> my
> > > tasks?
> >
> > Axis2 comes with the addressing module ... you can configure things
> > like wsa:To and wsa:Action using the axis2 client API.
> >
> > BTW your scenarios sound a lot like scenarios that can be supported
> > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > synapse-dev list as well)
> >
> > Thanks,
> > Ruchith
> >
> > Ref:
> > [1]
> >
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> curi
> > ty/src/org/apache/axis2/security/handler/config/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org