Closed adamgins closed 8 years ago
Based on the error you're getting, I'm guessing the claim rules you have set up with ADFS are not sending something that matches the requested NameID format which is causing ADFS to give up and throw an error. You could try changing the settings in ADFS, using a combination of 'Send LDAP Attribute as Claims' to send the email and then using 'Transform an Incoming Claim' to make that into an Email NameID. Or it may be easier to simply remove the nameid_format
key from sp_options
which would remove that requirement.
@jefff thanks heaps... that definitely helped.
We now have it working from both IDP and SP initiated requests when on the intranet using the Send LDAP Attribute as Claims
& Transform an Incoming Claim
However when going in via the internet via ADFS proxy we are seeing the following error:
s2at
2016-05-31 15:53:39+10:00Assert Error { [Error: SAML Response was not success!]
s2at
2016-05-31 15:53:39+10:00Assert Error 2 { 'urn:oasis:names:tc:SAML:2.0:status:Responder': [] }
s2at
2016-05-31 15:53:39+10:00 message: 'SAML Response was not success!',
s2at
2016-05-31 15:53:39+10:00 extra: { status: { 'urn:oasis:names:tc:SAML:2.0:status:Responder': [] } } }
Any ideas pls?
Closing this. Thanks for the help and great package. I removed the optional params and it works.
Did you ever find a solution to your last post regarding the status:Responder err?
HI, any examples of working with ADFS 2.0 pls?
I have the package working when started from the IDP... hit hits my `/assert' URL and all works well.
When I have a Service Providider initiated request it redirects to the IDP, the user logs in and then when it comes back to the
/assert
url it dies with:Here's the code:
At the moment I removed / changed some of the params:
At that point I got the following error similar error. Apologies I have lost the log file (as I restarted servers).
Any ideas pls?