This is exactly what we did (as I replied in the other email), we were just passing a base64 encoded token over HTTPs, the
identification was done only once...Of course, one need to worry about setting up the server side to ensure a token can not be used
for 'life', etc...The other issue we had to face was that we didn't quite figure out how to avoid deferring the autorization
decisions (to do with letting a user do certain UI actions) until the request reached the server, some approaches have been
considered but we didn't implement them AFAIK...
cheers, Sergey
----- Original Message -----
From: "Cole Ferrier" <[email protected]>
To: <[email protected]>
Sent: Tuesday, January 26, 2010 9:35 PM
Subject: Re: How do i not have to validate a username/password on every call?
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.
