views:

44

answers:

0

Hello.

Where I work, there's quite a bit of discussion about web service security since we want to retire our (costly) PKI solution. The buzz at the moment seems to be secure remote password (SRP), which seems to promise equivalent resilience without the need for a trusted third-party. The downside is that it is not widely implemented, even though it was adopted into SAML 2.0 a few years ago.

So, here's what I'm thinking. I can create a pseudo-security token service (STS) web service, using SRP in the back-end logic. When the user account successfully authenticates, I'll update their password entry in our LDAP with a digital token (a password set to expire 10 minutes from the time of being issued) which I will also pass back to the user as the response. When the user then uses any of our applications, which will only have basic authentication (username / password), they'll pass in the token as their password.

In a nutshell:

  1. User <--> STS [SRP authentication]
  2. STS --> User [short duration password]
  3. STS --> LDAP [short duration password]
  4. User --> Some Application [user passes in short duration password which the application verifies against the LDAP]

I'm not really a security expert though. Could anyone comment if what I'm saying makes sense or is way out in left field?

Oh, and the reason I'm using a STS is that the SRP stuff can be a bit lengthy (several requests and responses). If we have a chatty web service, it would add quite a bit of overhead if they had to go through that for each and every request.

Thanks.