Hi, I guess its not a question of the user being on the definitions.xml file... its more of the user id having to be specified as part of a policy or configuration. Thats the way it seems to be with Rampart. I am also trying to find out the rationale for this as its quite not possible to have hundreds of policies, each for a user. I also wonder if what we are running here is a business service that mostly runs under a system identity and this user is about that identity. So end users would probably be authenticated much ahead, say in a User Interaction Control tier and once authenticated there further invocations to the business tier happens only under a restricted bunch of system identities.
Well thats as much as I can imagine for a justification. Lets see if there are security experts who can throw more light about this - I am not one ;-) - Venkat On 10/24/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > 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] > >
