Overview  Where can I find the custom properties for the WebSphere SAML web SSO TAI? The custom properties for SAML web SSO can be found in the IBM Documentation. See: SAML web single sign-on (SSO) trust association interceptor (TAI) custom properties for v8.5.5 If you want to see the custom properties for a version other than 8.5.5, use the Version drop-down at the top of the IBM Documentation page. How can I tell if my trace is from server startup? IBM support requires that traces be gathered from server startup. If you want to make sure that your traces are gathered from server startup, check for the following string in your trace:
Can the SAML TAI do SP-Initiated SSO with an AuthnRequest? If you read the IBM Documentation article SAML single sign-on scenarios, features, and limitations, you find a description of a "bookmark style" login flow at the end of the document. The bookmark style login flow emulates, but does not fully implement, a more traditional SP-initiated flow. This is the only SP-initiated login flow that the SAML TAI supports out-of-box. In WebSphere 7.0.0.39, 8.0.0.11, 8.5.5.7, 9.0.0.0 and later, you can achieve a traditional SP-Initiated login flow with custom code by implementing the com.ibm.wsspi.security.web.saml.AuthnRequestProviderinterface. The custom code that you provide builds the AuthnRequest to send to the IdP. Information on how to implement an AuthnRequestProvider for use by the SAML TAI can be found in the Enabling SAML SP-Initiated web single sign-on (SSO) IBM Docs article. Is HTTP-Redirect binding supported?The SAML SSO feature in WebSphere traditional does not support HTTP-Redirect binding; it only supports HTTP-POST binding. The following is a common error that is received from Azure when it is configured for HTTP-Redirect binding. If you get this error, your Azure idP needs to be reconfigured to allow for HTTP-POST binding in order to interoperate with WebSphere. AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding. How can I tell if trust association is enabled? In order for SAML web SSO to work, trust association must be enabled. If trust association is not enabled, the SAML TAI does not load and process requests. If trust association is enabled, you see this entry in the trace: [6/04/16 15:30:29:681 CEST] 00000000 TrustAssociat 3 Trust Association enabled: Trying to load the interceptors If trust association is not enabled, you see this entry in the trace: [6/04/16 15:30:29:681 CEST] 00000000 TrustAssociat 3 Trust Association not enabled For step to enable trust association, see the second bullet of step number 2 in the document https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/twbs_enablesamlsso.html">Enabling your system to use the SAML web single sign-on (SSO) feature How can I tell if the SAML TAI is configured? If trust association is enabled and the SAML TAI is configured, you see the following entry in the trace: [6/04/16 15:30:29:681 CEST] 00000000 TrustAssociat > loadInterceptor Entry If you don't see this entry in the trace, first see the previous section to ensure trust association is enabled. If trust association is enabled, see the second bullet of step number 2 in https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/twbs_enablesamlsso.html">Enabling your system to use the SAML web single sign-on (SSO) feature to use the administrative console to check your TAI configuration. How do I find my SAML TAI custom properties in a trace? You can find your SAML TAI custom properties in a trace by searching for the string sso_1.sp.acsUrl. Your first hit should look something like this (all on one line): {sso_1.sp.filter=request-url%=citizenportal, sso_1.sp.acsUrl=https://handicare.sogeti.be/samlsps/citizenportal?user_type=EXTERNAL, sso_1.sp.retryOnceAfterTrustFailure=true, sso_1.sp.targetUrl=https://handicare.sogeti.be/citizenportal, sso_1.sp.EntityID=https://handicare.sogeti.be, sso_1.sp.trustStore=IdPTrustStore, sso_1.sp.wantAssertionsSigned=true, sso_1.idp_1.SingleSignOnUrl=https://wwwint.socialsecurity.be/authenticate/ssaas/loginRequestListener, sso_1.sp.trustedAlias=ssaas-int, alternate.db.url=jdbc:db2://10.227.42.97:50000/HANDIC3, alternate.db.j2c.alias=PRDCuramCellManager01/s_Curam_DB2ADMIN, sso_1.sp.acsErrorPage=https://handicare.sogeti.be/HCSAMLProcessingError.html, alternate.db.driver=com.ibm.db2.jcc.DB2Driver, sso_1.sp.principalName=urn:be:fgov:person:ssin, sso_1.sp.uniqueId=urn:be:fgov:person:ssin, sso_1.sp.idMap=idAssertion, sso_1.sp.userMapImpl=be.handicare.ws.security.web.saml.SSINUserMappingImpl, sso_1.sp.login.error.page=be.handicare.ws.security.web.saml.GenSAMLAuthnRequest} After that, you see the properties parsed by the ACSTrustAssociationInterceptor: ACSTrustAssoc > initialize Entry CWWSS7074E: The key is not retrieved. The exception is:: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWSML7004E: The [KeyInfo] element in the Assertion element is missing or empty. If you get this error, it happens during signature validation. This means that the SAML runtime could not find a key to validate the signature in the SAML Assertion. There are three ways to fix this problem:
SAMLResponse could not be verified.com.ibm.wsspi.wssecurity.core.SoapSecurityException: Fail to decrypt EncryptedKey -or- CWWSS7074E: The key is not retrieved. The exception is: Fail to decrypt EncryptedKey The WS-Security runtime is used to validate SAML Assertions for the SAML Web Single Sign-on TAI component. The WS-Security trace entries required to debug this error are included in the SAML WSSO trace spec. When you get this error, do the following:
Both of these "Fail to decrypt EncryptedKey" errors can also be associated with a web service:
CWWSS8010E: The SAML response Destination https://mycompany1.com/samlsps/wps/ is not for the service provider https://mycompany2.com/samlsps/wps/ This error generally occurs when there is a conflict between the values two or more acsUrl custom properties. The value for each service provider's acsUrl must be unique. Here is a description of the requirements for the acsUrl custom property: The value for each sso_<id>.sp.acsUrl property must have a unique URL path. A URL path does not include the protocol and <hostname>:<port> parts of a URL string. For instance, https://here.com/samlsps/app/go and https://elsewhere.com/samlsps/app/go have the same URL path (/samlsps/app/go) so only one of them can be configured as an acsUrl entry. In the CWWSS8010E message in the problem statement, both of the acsUrl entries shown in the message have the same URL path (samlsps/wps), so they do not meet the requirements. If you get this message, check the acsUrl settings for each of your service providers to make sure each one of them has a unique URL path. Error in mapping credential for Trust Association: This error is emitted by core security's WebAuthenticator class. It is only emitted after a TAI has authenticated a user and exits without error. In the case of SAML, the SAMLResponse from the idP was validated successfully and the SAML TAI exited without error. For example: [2/2/22 14:13:43:674 CST] 000001cb TAIWrapper < negotiateAndValidateEstablishedTrust(): status code = 200 Exit [2/2/22 14:13:43:674 CST] 000001cb WebAuthentica 3 TAI [com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor] has been validated successfully. [2/2/22 14:13:43:674 CST] 000001cb WebAuthentica 3 Subject retrieved is [Subject: Private Credential: {com.ibm.wsspi.security.cred.cacheKey=saml_acs_tai:sso_saml20_n1631011985n315412204, com.ibm.wsspi.security.cred.uniqueId=https://sts.windows.net/tenantid//, com.ibm.wsspi.security.cred.realm=https://sts.windows.net/tenantid/, Saml20TaiSsoPartners=saml_acs_tai:sso_saml20_, com.ibm.wsspi.security.cred.securityName=, com.ibm.wsspi.security.cred.groups=[]} Private Credential: com.ibm.ws.wssecurity.platform.websphere.wssapi.token.impl.WasSAML20TokenImpl:(assertionID) ][2/2/22 14:13:43:674 CST] 000001cb WebAuthentica 3 Username retrieved from TAI is [] [2/2/22 14:13:43:674 CST] 000001cb WebAuthentica 3 Map credentials for . (snip ffdc) [2/2/22 14:13:43:705 CST] 000001cb WebAuthentica 3 Error in mapping credential for Trust Association: [2/2/22 14:13:43:705 CST] 000001cb WebAuthentica < Exiting with user_mapping_failed. Exit [2/2/22 14:13:43:705 CST] 000001cb WebAuthentica 3 first user mapping failed, continue login set to false When you get this error, it means that core security does not trust the realm associated with the user in the Subject. In the case of this example, https://sts.windows.net/tenantid/. If you get this error, do one of the following:
SAMLResponse could not be verified.com.ibm.wsspi.wssecurity.core.SoapSecurityException: unable to find valid certification path to requested target This error only appears in a SAML TAI trace. When you experience this problem without trace enabled, you get at least one ffdc entry that contains the following string: com.ibm.websphere.security.WebTrustAssociationFailedException: com.ibm.wsspi.wssecurity.core.SoapSecurityException: unable to find valid certification path to requested target If you are getting SAML login failures due to trust validation errors, you see ffdc entries from the SAML TAI similar to the following: [3/13/19 19:19:19:513 IST] FFDC Exception:com.ibm.websphere.security.WebTrustAssociationFailedException SourceId:com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor.invokeTAIbeforeSSO ProbeId:552 This error is logged at several code points, so the exact stack isn't as important as that it is from the SAML TAI and that the error is unable to find valid certification path to requested target. What this error means is that you have a truststore configured for the SAML TAI and that the TAI is unable to establish trust for the certificate that signed the SAML Assertion. The SAML TAI uses Java security to establish trust, therefore the rules for the Java runtime that you have installed are enforced. When you get this error, you most likely have one of the following issues:
As you can see, just from the perspective of fixing a trust validation problem, there are various issues that can be causing the validation problem and each issue can have one or more solutions. However, your specific problem at hand is that the certificate that your SAML IdP used to sign a SAML Assertion is somehow not trusted; this isn't a "general client using a general service" issue. The easiest way to solve this problem is to place the IdP's certificate into the truststore that the SAML TAI is using. To do this, you can do one of the following:
My SAML logins are in a redirect loop Consider the following scenario:
Two likely causes of this problem are:
This apparent login looping is occurring because the target server is rejecting the request for some reason. The best way to debug this issue is to review the logs or trace the target server in the other cell.
How can I retrieve attributes from the SAML token? After a successful login, the SAML Assertion that was received from the IdP is marshaled into a SAMLToken object and placed onto the WebSphere runAs subject. You can obtain this SAMLToken object and use methods to obtain its attributes and other settings. In v9.0, and starting in fix packs 7.0.0.43, 8.0.0.13 and 8.5.5.10, you can use WSSUtilFactory methods that were added with APAR PI62148 to obtain the SAMLToken object from the runAs subject. Here is some sample code: import javax.xml.namespace.QName; If you are running on a fix pack that does not include the WSSUtilFactory.getSaml20Token method, you can use the following sample code: import java.util.Set; When you run the SAML exportSPMetaData admin task, if you have the following SAML TAI properties configured, an encryption certificate should be emitted in the metadata output: sso_<id>.sp.keyStore If you are not getting the encryption certificate emitted in the metadata, check the following:
You will get a CWWSS8003E error when the StatusCode in your SAMLResponse does not equal the following value: urn:oasis:names:tc:SAML:2.0:status:Success When the StatusCode in a SAMLResponse does not equal urn:oasis:names:tc:SAML:2.0:status:Success, an error occurred on the idP side. Debug procedure:
Resolution: When you receive a status code that is not urn:oasis:names:tc:SAML:2.0:status:Success, an error occurred at the idP side. The values that you can receive vary depend on the implementation of your idP. Example failing status codes are:
Refer to your idP documentation for the definition of the failing status code that you have received. This version of the CWWSS8017E message can be confusing. It implies that there is a SAML SSO cookie missing, but the message is really talking about the LTPA cookie. The CWWSS8017E message, explanation, and action have been rewritten in a way that may assist you with problem determination: CWWSS8017E: No SAMLResponse parameter is specified in the HTTP request to the [{0}] endpoint. The request is redirected to the SAML identity provider for login. For SP-initiated SSO only, this error is expected for the initial request to the business endpoint and can be ignored. Explanation: This error occurs when all the following conditions are true: 1) Global security verification for the LTPA cookie failed, or the cookie does not exist. 2) The endpoint is protected by the SAML single sign-on (SSO). 3) No SAMLResponse parameter is specified in the HTTP request. The LTPA cookie might fail verification if one or more of the enforceTaiCookie SAML Web SSO TAI properties are set to true and there a SAML Assertion on the LTPA that is not scoped to the identified endpoint. User action: If the request is to the Assertion Consumer Service (ACS) URL, ensure that the identity provider (IdP) includes the SAMLResponse parameter on the HTTP request. If the request is to the business endpoint and the error is expected, but not wanted, perform one or more of the following actions: 1) If the enforceTaiCookie SAML Web SSO TAI property is set to true, set it to false. 2) If one or more of the sso_<id>.sp.enforceTaiCookie SAML Web SSO TAI properties are set to true, set them to false. 3) Increase the LTPA timeout. Common IssuesIssue 1 When performing bookmark-style SP-initiated SSO, the host name of your initial request URL from the browser must be the same as your acsUrl. The acsUrl is configured on the [sso_<id>.sp.acsUrl] TAI custom property. When WebSphere redirects the request to the Identity Provider (IdP), the browser associates the WasSamlSpReqUrl cookie that WebSphere creates with the host name associated with the request URL. The IdP must redirect the request back to the ACS URL. If the request URL host name is not the same as the ACS URL host name, the browser does not send the cookie with the redirected request. If the cookie is not present on the redirected request, the request cannot be redirected to the original URL after authentication. Things to think about:
|
The SAML authentication request property Subject is not supported and must not be set
zusammenhängende Posts
Urheberrechte © © 2024 defrojeostern Inc.
