Jens, Ruchith
It seems to me that what you need is WS-Trust. Basically WS-Trust
allows the client to get hold of a token and then attach that token to
all requests. Those tokens can then be accepted by any ESB or endpoint
that trusts the token server.
Does that sound like it meets your needs Jens?
Paul
On Fri, Mar 7, 2008 at 2:46 AM, Dimuthu Leelarathne <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Jens,
On Thu, 2008-03-06 at 19:33 +0100, Jens Goldhammer wrote:
> Hello together,
>
> I have thought about this scenario and I am having some problems
in my mind.
>
> client <-> esb 1<-> esb 2<-> service
>
> In terms of security aims I want to have autorisations mechanism
which I
> will get with this scenario. The esb 1 calls esb 2 and passes its
> credentials. So esb2 knows which esb will call the service and
can made
> an authorisation. The esbs encapsulate the real users which is
usefull
> in some cases. In my concrete scenario I want to have a tracing
> mechanism who (not only on esb level) was calling which service.
> How can I achieve this? If the client does not have the
possibility to
> include ws-security information in the message, I have no chance
for
> doing this, right? How should esb 1 know which user calls it?
Maybe I
> can make a ssl connection and pass the credentials in it, take
them at
> the esb1 and inject security credentials?
You can do this.
> If the client is a bpel-process, I cannot determine a real user.
In this
> case it is the bpel-engine?
> If the client is an web-application, I can use the
login-crediantials of
> the user to pass them to the esb 1. If I have the chance to do
that, I
> also can implement ws-security in the service itself.
Yes you can use web service client to pass login-credentials of the
user. Maybe you an use UsernameToken Authentication. As you
requested in
the previous mail, we can add methods to usermanager API to retrieve
password from the underlying user store. But taking the overall
picture,
I deducted that your clients can be bpel or a web service client.
But I
do not know much about bpen-engine to comment on that.
> Can you tell me the scenarios for switching security on and off?
Security cannot be switched on and off at the same service. If it is
absolutely required, what I would do is duplicate the service in two
places, one of them will be secured with WS-Security and the other
will
be without security.
Thank you,
Dimuthu
> Thanks,
> Jens
>
> Ruchith Fernando schrieb:
> > Let me try to answer your question with my understanding your
scenario.
> >
> > You have a set of ESBs and you can authenticate users at those
EBSs
> > using any of the mechanisms Dimuthu explained. Now in
situations where
> > one ESB has to talk to another *on behalf of* one of its users
that
> > ESB can authenticate itself to the other ESB and carry out the
work.
> > In this case each ESB will have their own credentials in the
form of
> > username/password pairs or certificates. And the communicating
ESBs
> > will have to trust each other by recognizing those credentials.
> >
> > HTH
> >
> > Thanks,
> > Ruchith
> >
> > Jens Goldhammer wrote:
> >> Hello Dimuthu,
> >>
> >> thanks for your good explanations!
> >> Which of these possibilities are valuable to have a
> >> cross-domain-authentification? With rampart I always have to
> >> distribute new certificates to all participating domains, or
I am
> >> completly wrong?
> >> Do you think the third possiblity works with wso2 esb? Should
I give
> >> it a try?
> >> Is there a running bigger example for using rahas except
sample05 in
> >> rampart-distribution or any documentation for it?
> >>
> >> Thanks,
> >> Jens
> >>
> >>
> >> Dimuthu Leelarathne schrieb:
> >>> Hi Jens,
> >>>
> >>> On Mon, 2008-02-04 at 18:42 +0530, Asankha C. Perera wrote:
> >>>
> >>>> Hi Jens
> >>>>
> >>>>> My ideas are to inject some user values in the soap-message
> >>>>> (username and password) and encrypt the soap-message. The
esb will
> >>>>> take these values and proofs it by using the wso2
usermanager.
> >>>>>
> >>>
> >>>
> >>> As I understand you need to authenticate users using
username/password.
> >>>
> >>> This can be done in several ways as follows.
> >>>
> >>> 1) Using http basic authentication over SSL
> >>> 2) Using Username Token over SSL
> >>> 3) Using an encrypted Username Token.
> >>> Implementation details of the above techniques can be
described as
> >>> follows.
> >>>
> >>> First method
> >>> ============
> >>> First approach is the easiest to implement and sufficient
for most
> >>> situations. You can write a simple Java POJO class at the
service to
> >>> authenticate users by calling usermanager. If you want a
more efficient
> >>> approach you can implement a custom mediator with a caching
technique
> >>> which uses usermanager to perform authentication.
> >>>
> >>> This is how you write a custom mediator [1]
> >>>
> >>> This is how you read the http authentication headers [2]
> >>>
> >>>
> >>> Second method
> >>> =============
> >>> This is a WS-Security policy based approach. Rampart is used
for
> >>> injecting and authenticating the Username Token. The
security policy
> >>> needed for this is available in the Rampart distribution[3].
The sample
> >>> is samples/policy/sample01 in the Rampart distribution.
> >>>
> >>>
> >>>
> >>> Third method
> >>> ============
> >>> This is a WS-Security policy based approach. Here you have
to use
> >>> Asymmetric Binding and use UsernameToken as a supporting
token. We
> >>> don't
> >>> have a sample for this yet. But you can look at the Rampart
samples and
> >>> read the WS policy specification for this.
> >>>
> >>>
> >>> Links
> >>> [1]http://wso2.org/library/2898
> >>>
[2]http://www.mail-archive.com/[EMAIL PROTECTED]/msg00065.html
<http://archive.com/[EMAIL PROTECTED]/msg00065.html>
> >>>
[3]http://www.apache.org/dyn/mirrors/mirrors.cgi/ws/rampart/1_3/rampart-1.3.zip
> >>>
> >>>
> >>> Thank you,
> >>> Dimuthu
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> Sure, this is possible with a custom mediator or a simple
Java POJO
> >>>> class that calls into the usermanager library. You could
also use
> >>>> WS-Security without coding using a WS-Security policy. I am
copying
> >>>> Dimuthu from the usermanager/Rampart team so she could
point you in
> >>>> the correct direction. We have some samples that shows how
WS-Sec can
> >>>> be used with policies
> >>>> (http://wso2.org/project/esb/java/1.6/docs/ESB_Samples.html)
> >>>>
> >>>>> After a successfull authentification I have to indicate
that they
> >>>>> other esbs and services itself don´t need to proof it
again. I don´t
> >>>>> want to make a new authentification at all intermediate
stations, so
> >>>>> in my eyes a flag in the soap message to say "Already
authenticated"
> >>>>> is enough, or?
> >>>> If this is totally within your intranet, I guess this
should be
> >>>> enough. You could also use https to secure the messages
over the wire
> >>>>
> >>>>> I have to write an own mediation than, right? Or is there
a solution
> >>>>> out of the box?
> >>>>>
> >>>> Well you could use the Header mediator to add a custom SOAP
header to
> >>>> a message
> >>>>
(http://wso2.org/project/esb/java/1.6/docs/ESB_Configuration_Language.html)
> >>>> You could also use a custom extension mediator if you like,
but
> >>>> this doesn't seem necessary
> >>>>
> >>>>> What´s about the identity solution? Does it fit to my
> >>>>> requirements? Any other ideas in general for doing that?
> >>>> If you want to call into the user manager library and add
the custom
> >>>> header both at once etc. writing a custom mediator may be ok
> >>>>
> >>>> asankha
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Esb-java-user mailing list
> >>> [email protected] <mailto:[email protected]>
> >>> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
> >>>
> >>
> >> _______________________________________________
> >> Esb-java-user mailing list
> >> [email protected] <mailto:[email protected]>
> >> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
> >>
> >
> >
> >
> >
_______________________________________________
Esb-java-user mailing list
[email protected] <mailto:[email protected]>
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
