Hi Julian,
The mapping rule I sent above specifically sets the "type" of the name field to be correct so I don't understand why the incorrect value is still being sent.
Perhaps add another trace line at the end of the mapping rule to make sure the values are set correctly:
IDMappingExtUtils.traceString("idp mapping rule final stsuu: " + stsuu.toString());
With trace enabled, do you see these messages in the runtime trace.log? It would be a good idea to be certain that the mapping rule is being executed because to me most likely explanation is the mapping rule is not actually being run right now.
If you can't fix this you may need to open a support ticket.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Sat January 09, 2021 11:08 PM
From: Julian Fazri
Subject: ISVA - Troubleshoot SAML SSO in Application
Hi Jon,
There's another case. I am using this mapping for another Identity Provider configuration (I have try with your mapping rules too), but the SAML response doesn't change nameid-format into emailAddress. It seems all my mapping rules has the same mapping, because when I check all saml response that I configured it doesn't user email address for nameid.
This are one information from my Service Provider
Identity provider is not configured correctly. NameIdFormat is not valid.
Provided: urn:ibm:names:ITFIM:5.1:accessmanager
Expecting: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Is there any configuration I miss?
Thanks.
Regards,
Julian
------------------------------
Julian Fazri
Original Message:
Sent: Tue December 01, 2020 06:25 AM
From: Jon Harry
Subject: ISVA - Troubleshoot SAML SSO in Application
Hi Julian
Try using something like this as the mapping rule. You can set at federation level or (override) at partner level:
// SAML20 IP Mapping ruleimportPackage(Packages.com.tivoli.am.fim.trustserver.sts);importPackage(Packages.com.tivoli.am.fim.trustserver.sts.uuser);importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);IDMappingExtUtils.traceString("idp mapping rule called with stsuu: " + stsuu.toString());// re-write Principal name with type as email nameid formatvar principalName = stsuu.getPrincipalName();stsuu.getPrincipalAttributeContainer().clear();stsuu.addPrincipalAttribute(new Attribute("name", "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", principalName));// example of adding a new onevar testAttr = new Attribute("client","urn:client", "client");stsuu.addAttribute(testAttr);
You can see that this rule replaces the Principal "name" attribute with a new one that has the type set for standard SAML email format (which you can use with any string-based username).
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Tue December 01, 2020 05:53 AM
From: Julian Fazri
Subject: ISVA - Troubleshoot SAML SSO in Application
Hi Jon,
Thanks for your suggestion, I get more vision now.
But there is new issue, I can generate the token now and there is no error in Verify Access, but there's a error message like this on application.
[SsoAuthenticatedStateSAML] Invalid SAML response: Not supported <NameId> format in SAML response: urn:ibm:names:ITFIM:5.1:accessmanager
Do you have any workaround for this?
Thanks.
Julian
------------------------------
Julian Fazri
Original Message:
Sent: Mon November 30, 2020 05:14 AM
From: Jon Harry
Subject: ISVA - Troubleshoot SAML SSO in Application
Hi Julian,
As you said, the logs you've posted here don't show much useful information. From the Reverse Proxy request log I can see that you were eventually able to login to the Reverse Proxy and call the SAML endpoint - but from the log at your SP, it looks like the SAML request did not succeed because the response status was NOT success.
The "IdP message" shown in the SP log is a base64 encoded message. From the text version of that it would probably be possible to decode it which might give some indication as to what the error was but you have only included a screen shot.
To find additional information on the Verify Access side, you should look in the federation runtime log. This can be found under monitoring in the LMI by looking for a messages.log file under either Federation or Advanced Access runtime (they are the same Java process).
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Thu November 26, 2020 02:07 AM
From: Julian Fazri
Subject: ISVA - Troubleshoot SAML SSO in Application
Hello Guys,
Could anyone help me?
I am currently using ISVA 10 and create a federetion where my ISVA as an Identity Provider I have configure web application as a Service Provider for SAML SSO to this application. But there is still an error when doing the SSO.
How to troubleshoot this problem and where can I find logs for this error on my ISVA? I check some logs in ISVA and my application but still cannot find how to solved it.
I post some logs capture on webseal and my application, but I dont know it's related or not.
------------------------------
Julian Fazri
------------------------------