I am using omniauth-saml 1.3.1 with omniauth 1.2.2 in rails 4.2. It works well with my test identity provider set up at openidp.feide.no (a nifty tool for those setting up a SAML service provider). It even works in production.
Now I am trying to get an IdP set up with a client of mine. When the user visits /auth/saml, they are directed to the client's IdP as expected. The user is able to use their email/pw to login.
The IdP then responds to my SP, but omniauth is redirecting to the failure callback.
As seen here, I get an error message "invalid_ticket". However, the error itself isn't getting passed to my failure controller action in env["omniauth.error"], as I read it should somewhere (unfortunately I can't find that documentation right now).
I'm hoping somebody will have some advice as to how I can figure out what is causing the "invalid_ticket" to happen. Is there perhaps a way to see the raw SAML response from the IdP?
I should note that I need to find this information in production because the client's IdP points to our production SP and I can't convince them to point it somewhere I can do some more extensive testing (like my localhost dev machine). I can, however, write in some more logging or Honeybadger exception reporting if that will help.
Currently, I am reporting to Honeybadger all env["omniauth.*"] values and params when omniauth redirects to the failure route, but I am not getting any information further than Omniauth message: invalid_ticket.
A big thank you to anyone who can help me go in the right direction here!
You might want to try adding other environments to failure_raise_out_environments:
OmniAuth.config.failure_raise_out_environments = ['development', 'staging', 'production']
to your initializer. You will get meaningful error messages in your log or Honeybadger.
These errors are by default raised only in development environment.
Related
I am facing some issues to implement SAML SSO integration. The system I am working with use Zammad (Ruby on Rails) as framework, and omniauth-saml to make the SSO flow.
What happens is that everything goes very well until the Auth0 server call system's callback. Then, omniauth_saml calls failure_omniauth and generate the following logs:
But, as you can see by the logs, after that omniauth-saml returns an uncommon error that I just don't really know what it means.
Here's the code around those logs:
I am trying to recover callback data and create a session for my user.
I am trying to register OAuth client, following the docs, but none of the links containing /developers in the path are working for me. I am either getting redirected to the https://my.tapkey.com/AdminUI/ and infinite load, until i refresh the page, or getting status code 502 Bad Gateway.
The ones I am having problems with are:
https://my.tapkey.com/AdminUI/developers/oauth-clients
https://my.tapkey.com/AdminUI/developers/identity-providers.
I tried on different OS's, using proxy, but nothing worked for me.
I am trying to register OAuth client, and explore more of the TapKey web api, but this one is a blocker for me.
You caught us here - we have changed the website a bit, and updated documentation is on its way but not yet published. We are working on it right now.
Developer section has moved to Tapkey Integrator Portal available on https://portal.tapkey.io .
Use the same login credentials you are using with Tapkey.
How can I setup PAW to work with Facebook locally for development? Or even at all for that matter?
I have a node.js backend that I'm setting up with Facebook Auth. Every one of my routes needs the user to be logged in. I have two endpoints related to FB Auth. localhost:3000/api/v1/loginFB and localhost:3000/api/v1/callbackFB. Both of these work great in a web browser.
loginFB simply returns this string... https://www.facebook.com/dialog/oauth?client_id=523534457345&redirect_uri=https://localhost:3000/api/v1/callbackFB&scope=email,public_profile,user_friends.
When I call that URI in a browser, it returns a code=blahblah which my callbackFB endpoint uses to fire off another request to get the access token. All good.
So now in PAW I'm confused by the difference between the request URI and the Authorization URL text field? Should I use the loginFB URI for my request URI? And then https://www.facebook.com/dialog/oauth in the Authorization URL textfield?
Basically what's happening is that when I click Get Access Token, it returns the code but my callbackFB endpoint 500's by saying "This authorization code has been used." The code that it's getting returned is definitely different each time I Get Access Token.
This is where I'm at with this thing (Client ID and Client Secret are actually my App ID and App Secret from fb's dev management site, and the Access Token URL is actually set to https://graph.facebook.com/v2.3/oauth/access_token which I'm 99% sure is the correct URI):
This is the error I get when I click Get Access Token button:
It would be awesome to get some advice from anyone with experience with this issue. Thanks.
Re: #MichaMazaheri
tl;dr Fixed in version 2.2.2
Sorry for the super late follow-up. We actually fix this exact issue in Paw 2.2.2, which is already released on our website, and pending review for the Mac App Store. (It was some JSON vs. Form URL-Encoded parsing issue). Thanks for reporting.
I have a Silverlight 5 app that runs on a SharePoint 2007 site. The Silverlight app gets a bunch of data from SharePoint lists using the Lists.asmx service. The main site is secured using NTLM security and Silverlight is able to successfully call the web services without having to eplicitly set anything to do with authentication. We extended the SharePoint site to a second domain that uses asp.net FormsBasedAuthentication. On this version of the site, the first web service call fails with a 403 Forbidden response and the exception:
System.ServiceModel.CommunicationException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
As I understand it, this is a generic message and not the true exception. Well, obviously we need the real exception to have any idea what the problem is. This MSDN page (Creating and Handling Faults in Silverlight) offers two solutions to getting the real exception.
The first is to modify your WCF service to return an alternate HTTP status code. This doesn't work because for one, it is not a WCF service, it's an .asmx web service so I can't add the suggested WCF behavior to modify the status code. Second, it's SharePoint's service so I can't do much to modify it anyway. Could I modify IIS to achieve an equivalent solution somehow?
The second solution is to register an alternative HTTP stack in the Silverlight application. I tried this out and found out the "real" exception was an authentication exception. So I went down dead ends trying to figure out out to get authenticated for about 24 hours only to finally find out that normally, the ASP.NET authentication cookie is passed with the service request, unless you are using the Client HTTP stack. So registering the client HTTP stack allowed me to see real exceptions, but it created its own exception which seems to only be fixed by not using the Client HTTP stack...
I believe have verified with Fiddler that the authentication cookie is being sent when using the default HTTP stack. I don't know if the Lists.asmx service is unable to use it and is giving an authentication error anyway, or if there is some other exception. How can I determine the cause of the "The remote server returned an error: NotFound." exception?
Well, this isn't a good answer to the quesion "How can I determine the cause..." but it's what worked for me. What I did was open up STSSOAP.dll, the assembly containing the Lists service implemention, in reflector. I copied the relevant code to implment my own GetListItems method in my own service. Luckily, the actual Lists.GetListItems method code was minimal and just called other SharePoint methods and even luckier, those methods & members are all declared public so I was able to do this. I then replaced Lists.asmx with my version on the server and attached the debugger to get some info. What I found was my authentication cookie was being used and HttpContext.Current.Session.User.Identity.IsAuthenticated was true. So it knew I was logged in. But I was still getting an authentication error which I could see farther down in SharePoint's code, was converted to a 403.
So I know asp.net considers me authenticated but SharePoint says I don't have permissions. But the service account the app pool is running under is a SP admin so why don't I have permissions? So next I inspected the SPContext.Current.Web.User; SharePoint's current user. It was null! In other words, as far as SharePoint is concerned, I'm still logged in as an anonymous user because I haven't explicitly logged in with a domain user, and an anonymous user doesn't have permissions on the list I'm accessing or most of the rest of the API. The answer by Sean McDonough to this quesion lays it out.
Basically I need to run the involved code with elevated privileges to get the code to run under the asp.net service account that I originally thought it was running under. If using the API, you can use the RunWithElevatedPrivileges delegate. But if you're calling the web services, you can't do that. The few options I could think of were:
Call the services on the base site that uses Windows Authentication. This would require me to embed the credentials in the client-side Silverlight application which is a security threat so I nixed this one.
Implement my own web service to get the data for me.
The web service could access the list using the SharePoint API and
RunWithElevatedPrivileges.
The web service could call the Windows Authentication site's services passing the current credentials or other embedded credentials.
For implementation ease, all I've done so far is the second option under number 2 and it's working. However, it is clunky and I may change to option 1 which I expect will also work.
I am using django all-auth for authenticating users via social networks so, when I'm trying to login via facebook/google/twitter through url:
http://127.0.0.1:8000/accounts/socialnetwork/login
( here socialaccount is facebook/google/twitter), I'm able to login successfully and then getting redirected to:
http://127.0.0.1:8000/accounts/profile/
but when I'm going to url:
http://127.0.0.1:8000/accounts/socialnetwork/login/callback/
I'm getting this error "an error occured while logging via social network" but could see "signout" and "change email" options if I'm already logged in.
Also,when I'm going to
http://127.0.0.1:8000/accounts/social/connections/
sometimes I can see only google and twitter accounts, sometimes only facebook accounts but not both depending upon my site_id in settings.py.
Now I'm really confused whether this is an issue with my callback urls or my site domains or something else.
You mention that visitting http://127.0.0.1:8000/accounts/socialnetwork/login/ (where I assume socialnetwork is one of google/twitter/facebook) works fine. Congratulations! -- because these are the proper entry points for logging in with a third party provider.
You should not be visitting the callback url directly yourself. It is meant to be redirected to by the third party provider. In doing so, it passes along authentication related codes that can be used to login. If you visit the url directly these codes are not passed, hence, the system will complain with "an error has occurred"...
As for the issue with respect to the social connections url: what you see here is all third party accounts connected to the local user account. So, if it varies from time to time I can only assume you are logging in under different accounts - which implies different connected third party accounts.
There is a fair amount of confusion for me around what values go where, there is an APP_ID from Twitter that seems to be useless unless you are filing a support request but somehow from the docs I got the idea that that was the value I needed to put into the CLIENT_ID, but NO, you need to put in the API_KEY there.... The lack of good logging/display of the errors by the template (because of a malformed exception text) makes it hard to figure out what is going on. Luckily I set a breakpoint and found the real error, changed the values around and voila, it was working....
Not sure who is at fault here, allauth or twitter, but it would help if everyone could get on the same page when it comes to naming things.