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]> 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 > > >>> > [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] > > >>> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user > > >>> > > >> > > >> _______________________________________________ > > >> Esb-java-user mailing list > > >> [email protected] > > >> http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user > > >> > > > > > > > > > > > > > > > _______________________________________________ > Esb-java-user mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user >
_______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
