[ADFS2.0] Rollup 3 がリリース

今月はシアトルに来ていたりするので、前後を含め色々と忙しくてこんなネタばっかりです。。

AD FS2.0 Rollup 3 がリリースされています。
　http://support.microsoft.com/kb/2790338

これまでの Rollup では機能拡張があったのですが、今回はバグフィックスのみです。
- Rollup 1 / Office365 対応の強化
　http://idmlab.eidentity.jp/2011/10/ad-fs20-rollup-1-office-365.html
- Rollup 2 / SAML 仕様対応の強化
　http://idmlab.eidentity.jp/2012/05/ad-fs20-rollup-2.html

• Issue 1
• AD FS 2.0 does not issue an ActAs token for a relying party who is using a Security Assertion Markup Language (SAML) 2.0 bootstrap token. When this issue occurs, the following error is generated:
• System.IdentityModel.Tokens.SecurityTokenException: ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.
• After you apply AD FS 2.0 update rollup 3, AD FS 2.0 successfully issues the token in this situation.
• Issue 2
• AD FS 2.0 acts as a federation provider and receives an invalid SAML 2.0 signed request (for example, the signature is not valid or the requestor is unknown). In this situation, AD FS 2.0 rejects the request only after it forwards the request to the downstream identity provider and receives a valid SAML response.
• In order to make sure the validity of the requests that are sent to the downstream identity provider, the expected behavior is that AD FS 2.0 validates SAML requests and rejects any requests that have invalid signatures.
• Issue 3
• AD FS 2.0 update rollup 2 introduced strict Uniform Resource Identifier (URI) checking. When AD FS 2.0 acts as a federation provider and trusts an identity provider whose identifier is not an URI, the response that is returned from the identity provider is rejected by AD FS 2.0. The validation fails because AD FS 2.0 tries to validate the value of the identity provider’s identifier. This behavior breaks previously functioning AD FS 2.0 deployments in which identity providers use non-URI identifiers. AD FS 2.0 update rollup 3 removes this URI checking.
• Issue 4
• Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 is capable of allowing unique signature certificates to be applied to a relying party trust, but it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction and allows multiple relying parties to use the same signing certificate for SAML request.
• Issue 5
• Consider the following scenario:
• You use a third-party hardware security module (HSM) to speed up the signing processes.
• You use the third-party HSM and to generate and store the private keys.
• The private keys are for AD FS 2.0 signing and for AD FS 2.0 encryption certificates.
• In this situation, the performance of AD FS 2.0 is not as good as when you use Microsoft CSP. AD FS 2.0 update rollup 3 significantly improves the performance of AD FS 2.0 when HSM is used.
• Issue 6
• AD FS 2.0 update rollup 1 introduces the Congestion Avoidance Algorithm. If you accidentally disable the Congestion Avoidance Algorithm by changing the configuration, a handle leak occurs on an AD FS 2.0 federation server proxy every time that the federation server proxy processes a request. AD FS 2.0 update rollup 3 removes the setting that enables you to disable Congestion Avoidance Algorithm by changing the configuration. You can fine tune the Congestion Avoidance Algorithm by adjusting the latencyThresholdInMsec and minCongestionWindowSize settings.