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: [email protected] > > 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: [email protected] > > > > 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] > >
