Some of our users are encountering the following error page during the sequence of redirects after authenticating at their IdP.
"Unexpected exception occurred in Response Handling: null"
Partner: ...
Target: ...
This is what I believe is the corresponding info from the the server log.
2015-07-16 07:48:53,458 DEBUG [com.pingidentity.jgroups.MuxInvocationHandler] invocation of saveState on InterReqStateMgmtMapImpl state map size:215 attributes map size4 w/args: [ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB, State(1437050933419){
inMsgCtx=null
outMsgCtx=OutMessageContext
XML: <samlp:AuthnRequest Version="2.0" ID="E6_0yldGrt0iqNKfUpArog6DG8G" IssueInstant="2015-07-16T12:48:53.419Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">#issuer%</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/>
</samlp:AuthnRequest>
entityId: <Id> (IDP)
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
relayState: ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB
Endpoint: <endpoint>
SignaturePolicy: DO_NOT_SIGN
parameters=null}] returned null
Is there an obvious place to look for more details? This happens for around 10% of our users and seems to follow them from device to device.
I figured out what the issue was. We are using account linking using the SAML Subject from the IdP. It turned out that a number of accounts at the IdP didn't have the LDAP attribute mapped to the NameID populated. So we were receiving SAML assertions without any data in the Subject.
Understanding where to look is the key. The audit.log file shows a general "failure". Then you look up corresponding activity details in the server.log file. Then you examine the corresponding SAML assertion in the log to determine what the problem was. The difficult part is noticing omissions in the data. That's harder for the eye/brain to catch imho.
It would be useful if we had an option for directing users to a custom page rather than a Ping-specific error page when this occurs.
Related
I'm currently using the sabre web service TravelItineraryReadLLSRQ (version 2.2.0) and I can successfully retrieve all on the PNR data. Now I'm trying to implement GetReservation but I'm getting the error below.
Not finding any further detail from the dev sabre portal - has anybody seen this and know what the 'fix' is?
"Viewership is restricted for the PNR, caused by [Viewership is restricted for the PNR (Unsupported security check), code: 700102, severity: MODERATE]"
<GetReservationRS xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Errors xmlns="http://webservices.sabre.com/pnrbuilder/v1_18">
<Error>
<Code>700102</Code>
<Message>Viewership is restricted for the PNR, caused by [Viewership is restricted for the PNR (Unsupported security check), code: 700102, severity: MODERATE]</Message>
<Severity>MODERATE</Severity>
</Error>
</Errors>
</GetReservationRS>
You may want to try using "Stateful" since "Stateless" is only intended for airline customers. You can use Stateful together with a locator or without it, makes no difference.
You may also may want to be aware that the service can be called with the Full, Default and Simple View Names. Only Simple will return more updated data which you can obtain by using the required subject areas in the payload. Full and Default will ignore the subject areas you use.
I've tried everything possible, to setup nJupiter.DataAccess.Ldap as the membership provider on our intranet based web application built using asp.net 3.5.
Challenges I am facing:
Not able to authenticate the user using the default login webpart (says Your login attempt was not successful. Please try again)
I tried this code and I receive a COMException : "There is no such object on the server."
var ldapMembershipUser = System.Web.Security.Membership.GetUser("username") as LdapMembershipUser;
if (ldapMembershipUser != null)
{
var givenName = ldapMembershipUser.Attributes["givenName"];
}
I have placed my web.config and the nJupiter.DataAccess.Ldap.config here:
web.config : http://pastebin.com/9XdDnhUH
nJupiter.DataAccess.Ldap.config : http://pastebin.com/WsSEhi98
I have tried all possible permutations and combinations for different values in the XML and i am not able to take it forward. Please guide. I just am not able to connec to the LDAP and authenticate the user or even search for users.
Just looking at your config is unlikely to be enough since I don't know your Domino server's confguration, so my answer isn't an attempt to fix your problem. It's an attempt to teach you how I would approach it if it were my problem. Here's what I do to troubleshoot connections and queries from code to Domino LDAP:
Configure the Domino LDAP server for logging the highest level of debug information with the notes.ini setting LDAPDEBUG=7. See this IBM technote for more info.
Use an LDAP client and figure out how to successfully connect to the Domino LDAP server. I like the free Softerra client for this. Check the logs and save off the info from your successful connection.
Now run your code and compare what you see in the logs against the successful connection.
If the code is making it past authentication but failing on the query, then find the actual query in the log, go back to your LDAP client, figure out what the query should have been, and adjust your code's configuration appropriately.
I am trying to validate a SAML response which is coming from Siteminder IDP from a third party. I have installed the certificate provided by them. When I call the ValidateToken method (System.IdentityModel.Tokens) to create claims, I get following error :
WIF10201: No valid key mapping found for
securityToken:'System.IdentityModel.Tokens.X509SecurityToken' and
issuer: 'issuer uri'
I dug in deep to find the error and its being thrown by method GetIssuerName (System.IdentityModel.Tokens).
Where is the problem? I googled for this issue but didn't find anything specific to my case. Does the SAML token from my client have a problem or there is something I am missing in implementation. I am fairly new to federated auth so please excuse any inaccuracy with the terminology used.
Gaurav
Ok found the solution but could't quite understand the readon behind it (complete noob, will update the answer when I know more).
Followed this approach of converting the SAML2 response to WSFed response, then on that new token I ran my code, now the error is gone.
http://blogs.msdn.com/b/bradleycotier/archive/2012/10/28/saml-2-0-tokens-and-wif-bridging-the-divide.aspx
Note : you still have to override the validate token method (which I had originally done) to avoid the following error :
“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.”
Thanks.
You are probably missing a configuration that maps the issuer name (as specified inside the token) to the certificate (probably specified with a thumbprint). I guess you solve this with some configuration in your web.config. Have a look at p.e. Microsoft validating issuer name registry The page contains some sample configuration. Setting this up correctly depends entirely on your situation.
I wanted to make a note for future reference, since I also ran into this error but my resolution was different. I got the WIF10201 error in a custom MVC application that is using ADFS (3.0) claims-based authentication under Windows Server 2012. In the web.config of the MVC application, the thumbprint of the ADFS token signing key is recorded. It turns out, when the signing certificate is about to expire, ADFS creates a new key. The new key is marked "primary" and the old key is marked as "secondary" in the ADFS console (under AD FS/Service/Certificates). So in my web.config there was, of course, still the thumbprint of the old (secondary) key. As soon as I replaced it with the thumbprint of the new (primary) key, the error disappeared.
I would like to get a list of meetings on the server however when i do a https://example.com/api/xml?action=report-bulk-objects&filter-type=meeting replacing the domain with my connect domain i get an access denied response. I am signed in to the connect work space and I am in the admin group. What could be the cause of this?
response:
<results>
<status code="no-access" subcode="denied"/>
</results>
This should work if you're in the admin group, logged in, and submitting the request from the same browser that's logged in. You might try adding the session parameter to your request ("&session=breez123abc456def")
The value of the parameter must be that of the BREEZESESSION cookie set by the Connect server on your authenticated session. One of several ways to discover that is with the common-info API method: https://connect.example.com/api/xml?action=common-info It'll be in the /results/common/cookie element.
If this still isn't working, check the debug.log on the server(s) for the failing request; there should be additional information there.
I'm running a WCF client locally that always throws a MessageSecurityException with the text:
"An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail."
The Inner Exception Message Is:
"An error occurred when verifying security for the message"
I set up a trace and in that file I can see the "inner inner" exception message as:
"The 'Body', 'http://www.w3.org/2003/05/soap-envelope' required message part was not signed. "
The bindings all match perfectly between the client and the service with them all using netTcpBinding with the securityMode="Message".
The ServiceContract decorating the interface behind the service is:
[ServiceContract(ProtectionLevel = ProtectionLevel.None)]
What could be causing my errors? I'm no WCF expert so I if you need anymore information just comment. Any ideas on what to try would be helpful too, I just have no idea whats going on here.
By default, all messages are signed and encrypted in WCF, and why on earth would you ever want to turn that off??
So in this case, most likely, your client has encrypted and signed the message, but the server doesn't understand it because of your attribute on the service contract.
My recommendation: unless you have a very compelling reason, never tamper and change those settings - just forget about that attribute on your service and leave the defaults:
[ServiceContract(ProtectionLevel = ProtectionLevel.EncryptAndSign)]
or
[ServiceContract]
If you really have to turn it off, you need to turn it off on both sides of the conversation - both the client and the server must agree on whether or not messages are encrypted and signed.
Marc