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
