Thanks for the updates. I'm slowly starting to figure this out. A quick question though. What is the usefulness of putting the user in the defintions.xml file?
-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: Venkata Krishnan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 23, 2007 2:14 AM > To: [email protected] > Subject: Re: Handling authentication for non-web services? > > 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: [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] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
