I am missing something here.
You are using X.509 certs and then having login information? Are you not
issuing individual certs to each client/user? The only potential I can think
of that makes sense is distributed security (each app has same user base?).
If so, move the user base to its own service and link it to the X.509 there.
You can then call the service to identify the user. Yes, this slows things
down a bit, but SOA is about reuse more than performance (although the
latency is not generally that bad if these are all internal apps and the
maintainability shoots through the roof).

Signature
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*********************************************
Think outside the box!
*********************************************
> planning on using a X509 cert to validate that a business client is who
> they
> say they are. After we authenticate client, then we need a username and
> password to authorize users permissions. Should we store this in the SOAP
> header or just as part of the XML message structure?
cootmonster - 28 Mar 2007 02:46 GMT
The reason for the cert and user/pass I believe is this...
We are giving the capability of a 3rd party company to interface to our web
service. They will be distributing their software to their clients. So what
I thought we would have to do is use a cert to verify that it is from the 3rd
party software vendor, then use a username/password to authorize the actual
user on our system.
Does this make sense or is it overkill?
> I am missing something here.
>
[quoted text clipped - 12 lines]
> > password to authorize users permissions. Should we store this in the SOAP
> > header or just as part of the XML message structure?