Re: Cannot use usernameForCertificateSecurity with IIS application pool custom account
- From: stcheng@xxxxxxxxxxxxxxxxxxxx (Steven Cheng[MSFT])
- Date: Fri, 05 Jan 2007 09:19:53 GMT
{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hello Martin,
\par
\par I've discussed this with some other engineers and we've got some further progress. Your observations are correct. From the stack below, it seems like you are using SecureCoversation. By default, WSE 3.0 will do stateful SecureCoversations, and this requires the use of DPAPI? in order to encrypt the state of the conversation. This state is passed with each message with the SecurityContextToken so that the server doesn? have to maintain any state.
\par
\par When your App Pool is running under a Network Service account, encrypting using the DPAPI? will work, because it has a logon session. DPAPI? require this logon session to exist in order to work the way WSE is using it.
\par
\par One option is for you to do what you state below and have that interactive logon session when you change the AppPool? identity. Another approach is to turn off stateful SecureCoversation, which will in turn not use DPAPI? at all. Keep in mind that this requires the server side to keep track of the session state, so in the event of an AppPool recycle, this state is lost.
\par
\par If you really need stateful secure conversations, and just cannot do with interactive logon sessions, then there is a third approach of having that state be encrypted with the public key of an X509 cert. Typically, for secure conversations the STS (SecurityTokenService) issuing the SecurityContextToken (SCT) and the target service with which the client uses this SCT to talk to are one and the same, hence this is not an issue. It is only an issue if the STS and the Target Service aren? the same, in which case the public key will have to be the one that the target service can understand and decrypt.
\par
\par
\par Please let me know if you have any further questions.
\par
\par Sincerely,
\par
\par Steven Cheng
\par
\par Microsoft MSDN Online Support Lead
\par
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
- References:
- Re: Cannot use usernameForCertificateSecurity with IIS application pool custom account
- From: Steven Cheng[MSFT]
- Re: Cannot use usernameForCertificateSecurity with IIS application pool custom account
- Prev by Date: Re: wse custom headers
- Next by Date: RE: Odd problem with WSE
- Previous by thread: Re: Cannot use usernameForCertificateSecurity with IIS application pool custom account
- Next by thread: WSE 2.0 w/ WS-Security 1.0 (AKA Mutual Certificate Authentication 1.0)
- Index(es):
Loading