Ron, Interesting perspective.
I was planning to only expose the web services via HTTPS so there is less of a chance that the secret session key we would be passing back and forth to be exposed. I was planning to do "authorization" on every call. What i didn't want to have to do is "identification" on every call. The method that i required to use to validate the username and password on the initial connection is very heavy and expensive. I am trying to figure out if there a way that i can create a token that we would pass back and forth, that represents them as a authenticated user. Basically issue a token, and expect them to have a token, for the life of the session. Make sense? Cole Ferrier On Tue, Jan 26, 2010 at 1:02 PM, Ron Grimes <[email protected]> wrote: > If I may chime in here... > > My comment is meant to both offer my perspective and possibly have someone > enlighten me on a better way to do it. > > I would venture to say that most folks are deploying stateless web services. > In such cases, it's my belief that more validation is required - not less. In > line with this, I tend to assign a session Id on initial login, which must be > passed to each subsequent web service operation that is called. But, it's not > good enough to just know they passed you a valid session Id, since a user can > steal a session Id via HTTP request smuggling. > > Each service operation performs a dual validation. For example, a client > wants to view an invoice. He must pass to the web service both a session Id > and invoice number. The service first validates the session Id by retrieving > the customer user record associated with it. It then takes the passed in > invoice number, combined with the customer number retrieved via the session > Id, and uses that combined key to fetch the invoice record. > > This ensures that I'm not only getting a valid session Id from the client, > but that they are authorized to view the particular invoice number they are > requesting. > > Yes, it's expensive to do it that way, but I don't know of any other way to > make sure that a client is only making requests for data to which they are > authorized. > > Ron Grimes > > > > > -----Original Message----- > From: Cole Ferrier [mailto:[email protected]] > Sent: Tuesday, January 26, 2010 1:01 PM > To: [email protected] > Subject: How do i not have to validate a username/password on every call? > > So I think i need to clarify my question. > > Currently, i have basic WS-Security setup to authenticate a username > and password using a callback class. This is working. > > However, the steps that are required to do that are very very expensive. > > So i would like to build some sort of session. Basically authenticate > once, then rely on the fact they are already authenticated. > > I understand WS-Trust could potentially accomplish this? Any > information would be helpful, on how to get started. > > Basically the problem i have is validating username/password is way to > expensive to do on every call, so how can i work around that? > > Cole > > > > On Mon, Jan 25, 2010 at 8:28 AM, Cole Ferrier <[email protected]> wrote: >> Actually i did: >> >> http://cxf.apache.org/docs/ws-security.html >> >> "Username Token Authentication" >> >> >> >> On Mon, Jan 25, 2010 at 8:19 AM, KARR, DAVID (ATTCINW) <[email protected]> >> wrote: >>>> -----Original Message----- >>>> From: Cole Ferrier [mailto:[email protected]] >>>> Sent: Monday, January 25, 2010 7:59 AM >>>> To: [email protected] >>>> Subject: How to? Authenticate once then pass a token? >>>> >>>> Currently I've managed to add basic username/password security to my >>>> web services. >>>> >>>> How do i now change that so that i can authenticate on the first call >>>> and create a session and then just use a token after that. >>>> >>>> I'm doing a rather heavy weight operation to validate the username and >>>> password, so I don't want to do it on every call. >>>> >>>> Are there any examples of doing this? >>> >>> If you're really using "basic auth", this is actually pretty easy. I >>> did this very recently. You first set up your web.xml with webapp >>> security using BASIC auth. If you examine your HTTP headers in the >>> response from the authenticated service, you should see a "JSESSIONID" >>> cookie coming back. If you store that hash value in the client and then >>> append ";jsessionid=<hash>" to subsequent URLs (until the session >>> expires), it should work. If you're making this call from JSP with >>> reasonable tag libraries, these mechanisms may even happen without your >>> intervention. >>> >> >
