Hi, I have added some minor updates to the the helloworld-ws-service-secure and helloworld-ws-reference-secure samples to given an idea of how simple authentication around userid and passwords could be performed.
I have also added one more component that uses a policyset with ws-security-policy assertions for implementing message integrity - again courtesy - Rampart samples :) Hope all this helps a bit. Thanks - Venkat On 10/23/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi Jason, > > Here are some thoughts for your queries on the policies and enabling > authentication to leverage from an LDAP registry. > > - Our Axis2 based WS Binding uses the Apache Rampart module for enabling > security around the web services hosted by our SCA Runtime. If you look at > the sample helloworld-ws-service-secure and helloworld-ws-reference-secure > it uses simple user id and password based authentication. There is a > password call back handler in the sample that actually deals with looking up > a userId and password and verifying if it matches. This handler is probably > the place from where you might need to connect to your LDAP registry to > authenticate. I am not aware of Rampart handlers that can directly go over > to a specified LDAP registry and do this check, hence avoiding the code you > may now have to write in the handler. > > On your other issue with sockets, it seems to me that you are wanting to > do that for supporting rich clients. Though I am not sure if it would fit > your requirement maybe you could take a look at our binding-dwr (binding > based on direct web remoting) and the chat sample that uses this. > > - Venkat > > > On 10/20/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > > > > > > > -Jason > > > > > > > > > > ############################################################################ > > > > ############################################################################ > > ######### > > This electronic mail transmission contains confidential information > > intended > > only for the person(s) named. Any use, distribution, copying or > > disclosure > > by another person is strictly prohibited. > > > > ############################################################################ > > ############################################################################ > > > > ######### > > > > > -----Original Message----- > > > From: Simon Laws [mailto:[EMAIL PROTECTED] > > > Sent: Friday, October 19, 2007 2:21 AM > > > To: tuscany-user@ws.apache.org > > > Subject: Re: Handling authentication for non-web services? > > > > > > On 10/19/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > > > > > > > That's a lot of text to scroll through, so I'll just add my comments > > at > > > > the > > > > top. > > > > > > > > In regards to how the service is selected, this is based on > > information > > > > within the message. Authentication simply determines if the message > > is > > > > allowed to pass on. > > > > > > > > > In regards to the protocol between tomcat and the service, once > > > > authentication is accepted, the message is simply forwarded to the > > > > service. > > > > The service itself handles the entire message parsing. > > > > > > > > > There seem to be some alternatives here then. > > > > > > Convert the current services to SCA Components and maintain the > > servlet > > > routing component. This would be my first suggestion to get you up and > > > running and give you a feel for what Tuscany can do. The servlet of > > course > > > needs to talk to the services. This can be done either locally or > > remotely > > > using a binding of your choice. So the servlet would need to be > > modified > > > to > > > hold references to services in the SCA domain. You can see examples of > > > Tuscany running in a web app, for example, calculator-webapp. These > > webapp > > > samples don't run as part of the distributed domain yet but I'm > > looking at > > > that at the moment. > > > > > > I don't want to give the impression that I think everything must live > > > inside > > > of SCA but just thinking aloud about some other things that could be > > > done... > > > > > > Based on what you have said already I'm assuming that you can't change > > > your > > > clients and that they currently provide the XML message as part of an > > HTTP > > > POST. > > > > > > Construct a gateway component (in place of the servlet) that accepts > > the > > > XML > > > over an HTTP binding. The function of the component would be to route > > the > > > message to wired components based on the contents of the XML. To make > > this > > > work we'd have to fix up binding.http to accept POSTed data. > > > > > > > On the OSOA page, there is a section on bindings that covers ws and jms, > > but > > I have been unable to find documentation on the http, rss, and atom > > bindings. Is there any documentation that outlines the schema for the > > various bindings available? > > > > > > > I've seen discussions recently about hosting web applications in SCA > > as > > > well > > > as the other way round. So in the future the solution maybe that you > > just > > > take the servlet you have and deploy that as a component. There's no > > > support > > > yet though. > > > > > > Construct a set of policies to handle the LDAP based authentication > > > activity > > > for binding.http . > > > > > > > I've seen the WS policies sample, but I'm still trying to figure the > > policies system out. If it's not a bother, can you give me a quick > > example > > on how I would deal with LDAP based authentication for the http binding > > given that user name and pw have been passed in the message? > > > > > If you can change your clients then there are of bindings that could > > be > > > used > > > while keeping the same XML message structure. > > > > > > > > > The service interface extends our own general MessageService interface > > > which > > > > has methods for receiving text messages it will have to parse as > > well as > > > a > > > > more specific service interface for places where services can make > > > method > > > > calls directly. > > > > > > I don't understand the last bit about "more specific service > > interface > > > for > > > places where services can make method > > > calls directly". Should it read "...where clients can make method > > calls > > > directly"? > > > > > > > In this case, I meant the service interface for a reference given to a > > service. This isn't that important given that all the service interfaces > > can > > be modified at the moment. We're actually moving into phase II of the > > project where phase I was just prototyping. So it can all be modified at > > the > > start of the new phase. > > > > > This was more or less an initial attempt at a roll-our-own service > > > component > > > > architecture if you will, before I even knew how to goggle those 3 > > words > > > > together. I didn't even know SCA existed until last week. HA! I > > don't > > > want > > > > to keep writing code for something that already exists. > > > > > > > > > Glad you found us! > > > > > > By TCP, I meant socket, to keep a persistent connection with our > > > application > > > > due to some real-time processing requirements, i.e. someone posts > > some > > > > information, we want it pushed as quickly as possible out to the > > > clients. > > > > As > > > > > > > > > We don't support TCP sockets directly. All of our bindings are > > currently > > > at > > > a higher level but of course ultimately built on TCP. Is it important > > > > > that > > > it is TCP or just that the client is listening waiting for a message? > > > > > > far as I can tell, this isn't possible with web clients. (We have both > > a > > > web > > > > front end and a thick client app to the program). > > > > > > > > > It depends how your web client has been written. For example, we have > > a > > > level of support for this kind of thing in binding.dwr which allows a > > fake > > > reference to be construct from services back to a web client. Under > > the > > > covers it is using some HTTP tricks to make it happen. > > > > > > The SCA programming model more generally has some concepts that might > > > help. > > > The implication of having an open socket between the client and a > > service > > > is > > > that the service holds state about this connection.Typically we try to > > > think > > > of services as being stateless but it is often that some state must be > > > maintained in some circumstances. It might be worth thinking about > > how to > > > formalize this relationship with callback and/or a conversational > > > semantics. > > > > Is there a sample on how to handle conversational sematics? I don't > > quite > > understand how this works yet. > > > > > > > > > > > -Jason > > > > > > > > > > > > > -----Original Message----- > > > > > From: Simon Laws [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, October 18, 2007 12:10 PM > > > > > To: tuscany-user@ws.apache.org > > > > > Subject: Re: Handling authentication for non-web services? > > > > > > > > > > Hi Jason > > > > > > > > > > I expect others in the project who are closer to some of the non > > web > > > > > services bindings will have their own views on this. Am setting > > the > > > ball > > > > > rolling by asking some questions. See below. > > > > > > > > > > As a general rule I would try and start simple so I wouldn't > > > necessarily > > > > > dive into thinking about new bindings, policies etc. in the first > > > > > instance. > > > > > Have a go with your front end and an SCA service behind it and > > then > > > > expand > > > > > from there. Even with this you might be facing the > > binding/databinding > > > > > question depending on you service interfaces but lets break the > > > problem > > > > > down > > > > > and see what the simple steps are. > > > > > > > > > > Regards > > > > > > > > > > Simon > > > > > > > > > > On 10/18/07, Jason Clark < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hello all. I am currently working on transitioning the project I > > am > > > > > > working > > > > > > on from it's current framework to Tuscany. It's already services > > > > > > based, > > > > > so > > > > > > that is making things easier. Currently, a custom formatted xml > > > > message > > > > > is > > > > > > posted through tomcat. When the servlet recieves it, it does > > some > > > > custom > > > > > > authentication against an LDAP server and then forwards the > > message > > > to > > > > > the > > > > > > appropriate service for processing. It's very much a roll your > > own > > > > > > solution > > > > > > right now. > > > > > > > > > > > > > > > Is service selection a function of authentication or is this based > > on > > > > some > > > > > information in the message? > > > > > What's the protocol between the servlet in Tomcat and the service? > > Is > > > it > > > > > the > > > > > sample XM message? > > > > > What does the service interface look like, i.e. the service that > > the > > > > > servlet > > > > > forwards to? > > > > > > > > > > I would like to better leverage existing technologies and Tuscany > > > > > > capabilities to improve this process. I need to continue to use > > the > > > > > > message > > > > > > format I'm using. Would I need to write a new binding since it's > > not > > > a > > > > > > format supported by JSON or WS? Or, would I keep doing what Im > > doing > > > > > with > > > > > > my > > > > > > current services just now registered on a domain and the servlet > > > > > receiving > > > > > > the message continue with the custom validation then use the > > domain > > > > the > > > > > > fetch the appropriate service to pass the message along to? > > > > > > > > > > > > > > > A new binding is certainly a possibility. What it sounds like you > > need > > > > is > > > > > a > > > > > some kind of REST binding to be able to "post" an XML document to > > a > > > > > service > > > > > "post" method. There are a couple of bindings that deal in > > arbitrary > > > > data, > > > > > I.e. binding.http and the feed bindings binding.rss and > > binding.atom. > > > > None > > > > > of these fit the bill directly but they we could potentially > > tailor > > > one. > > > > > > > > > > Raymond has been doing some work recently on building a demo > > showing > > > how > > > > > XML > > > > > can be handled (demo/xml-bigbank). This would be worth a look, for > > > > > > > example, > > > > > you can see in the AccountData service how he's dealing with an > > > > > XMLStreamReader. > > > > > > > > > > Venkat has been looking to policy intents to separate the > > > authentication > > > > > function from the details of the bindings. You can see an example > > of > > > > this > > > > > in > > > > > the helloworld-ws-service-secure and > > helloworld-ws-reference-secure > > > > > samples. > > > > > This might be the way to go in terms of associating LDAP based > > > > > authentication with any bindings you use. That would be a nice > > > addition > > > > to > > > > > Tuscany in it's own right;-) > > > > > > > > > > Also, how would I go about writing a TCP/IP window into the app? > > Just > > > > > write > > > > > > my own, or is there some support for this in Tuscany somehow? > > > > > > > > > > > > > > > What do you mean by a TCP/IP window? Socket? Where would that need > > to > > > > > provide access to? > > > > > > > > > > Pardon my ignorance. I don't quite know all the capabilities and > > best > > > > > > practices for dealing with this kind of problem, so I figure > > it's > > > > faster > > > > > > to > > > > > > ask, even it my questions don't make sense. > > > > > > > > > > > > > > > No problem at all. It's interesting to hear about your scenario. > > > > > > > > > > Thanks. > > > > > > > > > > > > Jason. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
