views:

788

answers:

2

So I'm trying to write a php SOAP client that requires the user to pass their login credentials for the remote SOAP server. Here is the set-up/dilemma:

  • User logs into local site using local credentials and goes to page with SOAP client.
  • User is now prompted for credentials for remote Soap server, which, by the way, are the same as the ones used to get into local site (9 times out of 10) via POST form.
  • Client passes credentials in the SOAP header along with the SOAP request, client outputs SOAP server response.
  • Script ends, user sees output data.

Now the user wants some other bit of data related to the original output. Problem is, that $_POST variable is now long gone. User must include credentials along with the next request. Repeat until user decides that it's easier to look up the data via another method and gives up on cool SOAP client.

The server hosting the Web Service can be accessed directly via a web client, and authentication is maintained via a cookie. However, when the server is queried via the WDSL, it doesn't look for any cookies or other browser-side session; it just checks that the SOAP request contains the credentials in the header.

So there are two versions of this question:

1) Is there a way for the local-session credentials to get passed to the SOAP request, thus keeping the logins down to one? (Be aware, I have no control over the authentication method even on the local side. This is handled by a home-grown Apache mod that controls authentication for any and every user throughout the system, covering dozens of departments I have no jurisdiction over. I have looked through the Global Variables and see no hint of the credentials, but I could just be daft about some basic security features of PHP/Apache).

2) Is there a safe and secure way for PHP to handle the credentials after the secondary login so that these credentials can be used for some set amount of time (say, a 30 minute session?). Keep in mind that, based on the first point, these credentials are very confidential, therefor there should be no simple way for someone to poke around and get these credentials to echo out (or get into some DB to see them, etc.)

Sorry if this sounds paranoid. I'm not used to handling security credentials beyond a simple "This is where you put in your password...Good, now that everybody knows each other for the rest of the session, I can get back to outputting useful stuff."

Even a link to any basic security features would be a helpful start.

A: 

Why don't you set a cookie yourself that has the username/password in it after the first soap request? You ask just one time then store in a cookie. You can then set a time out and query it while the user is logged in. You will probably want to delete the cookie on logout.

The cookie would contain the soap user/pass only. This way you would not have to worry about someone poking on the server and finding others credentials. This effectively does the same thing as having the user entering it every time since it is sent in clear text anyway. You could obfuscate the username and password in the cookie with a reversible hash or simple 2 way encryption.

Byron Whitlock
I'm actually reading up on php session security at:http://phpsec.org/projects/guide/4.htmlMy main concern is that the password is the same for quite a bit of other sensitive data, and I need to make sure that there is no chance that no one can decode a cookie or intercept a session. Even if I go to great odds to use a cipher of some sort and reverse the password and block any http means of accessing the decryption method, there is still going to be code that, should someone gain access to the server, draws a roadmap to getting the password.
Anthony
Quick Follow-up:If anyone knows...Is it possible to keep the SOAP client live via a SESSION variable so that only the client object has the password? I know it's not much better, but it may beat keeping the password in a designated SESSION variable.
Anthony
+3  A: 

Create your own expiration session. Create a database table which is:

CREATE TABLE session (
    ID int unsigned NOT NULL PRIMARY KEY AUTO_INCREMENT,
    Hash binary(16) NOT NULL,
    User int unsigned NOT NULL,
    Created timestamp 
);

When the user authenticates the first time, create the session and return the hex form of the Hash.

Subsequent calls do not require the user name and password, just the hash. After, say, 5 minutes of inactivity, the Hash is deleted. User name and password are passed just once, the hash is used as authentication thereafter, and expires after a period of non-use.

razzed