Javascript and SAML redirect fails - javascript

I try to access a resource at http://**/rest that is protected by Shibboleth SAML Serviceprovider. For that I make an XMLHttpRequest call to that address. On the resource server CORS headers are set and if there is no SAML Authentication everything works fine.
But if SAML Authentication is activated I get the following error in Chrome:
XMLHttpRequest cannot load *****/rest. The request was redirected to 'https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=********', which is disallowed for cross-origin requests that require preflight.
If I have a look at the network console I can see the following requests:
1.
Request URL:http://<resource_server>/rest
Request Method:OPTIONS
Status Code:200 OK
2.
Request URL:http://<resource_server>/rest
Request Method:GET
Status Code:302 Found
Response-Header: Location:https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=*****
So it seems that redirect will be initialized but then stops because of the error above.
Does anyone have any ideas how I can get this working?
Regards
Philipp

The 302 response is not an error. That is how a SAML protected resource requests authentication: by redirecting the user to the identity provider. Since you are making an AJAX call, however, the browser cannot follow the redirect to be authenticated.
Assuming the common Web Browser SSO Profile: The browser client needs to establish an authentication session in the same application that supports http://**/rest before you make the AJAX call. Most authentication session states are managed with cookies, so i would expect that once you have a session cookie for the application, the request to http://**/rest + the session cookie will result in a success.
There is also the Enhanced Client or Proxy (ECP) Profile. This would require passing on the authentication SAML payload from the IDP to the resource - see the spec https://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf .

Related

How i can solve the Forbidden (403) React.js framework?

I am working with React.js framework on my project, all is well only when I try to update data, always seen Forbidden (403).
I don't think its a problem with react.
According to MDN web docs :-
403 Forbidden
The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it.
This status is similar to 401, but for the 403 Forbidden status code re-authenticating makes no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.
It means you don't have permission to that endpoint, maybe because of you are not added the credentials (password, jwt, token or something like that which authorize the request) to the request header in react front-end.

Cors and preflight errors with axios in vue

In my application I have got laravel as backend, jwt-auth as authentication, socialite as oauth2 provider and vue as my frontend.
Now I use axios to authorize the user by github for example (https://github.com/login/oauth/authorize) inside the client and then get the access token by the backend api.
If I do the authorize request with POSTMAN everything works, but if I do the request with my frontend axio request I get always errors. I think I get them because some Header values which are not correct. Can someone explain me which variables an axion request needs to perform an authorization request.
Kind Regards.
you can either disable cors in your browser which is very bad or you have to enable cors in your backend and to check if cors is enabled in your backend look for Access-Control-Allow-Origin header in browser network tab or you have to use proxy so that the requests are made to the same origin as seen by the browser but are redirected to some other url.
In create-react-app this works by adding
"proxy":"http://youUrl:portNo."

CORS Issue with AJAX redirect to SAML 2.0 Identity Provider

I have an Angular web application that I'm hosting on an Apache web server that's configured with the mod_auth_mellon module. With mod_auth_mellon, my Apache server acts as a Service Provider with a SAML 2.0 Identity Provider (iDP), for which I have an established Relying Party Trust.
Once authenticated, the web application will fire off an AJAX call in the background every minute. This call goes through a reverse proxy that I've set up on the Apache server.
The typical browser flow: Once the Apache mellon session (MellonSessionLength) expires, any request going through Apache will redirect back to the SAML iDP to re-negotate. Assuming I'm still authenticated with the iDP, mellon will establish a new session and automatically redirect me back to my original destination. Normally, this re-negotiation is an extra request or two that happens seamlessly behind the scenes.
The problem: The mellon session will typically expire when my background AJAX request is firing, which redirects that request back to the iDP. On the AJAX request back to the iDP, the browser is giving a CORS error and the response includes a generic log-in page (rather than my redirect destination). My (Apache) requests should appear to originate from the same domain as the iDP, but not the same subdomain (but, in reality, they are two different servers): (mywebapp.mydomain.com vs. idp.mydomain.com). If I simply copy the request URL into the browser bar manually, the re-negotiation happens without a problem.
Question #1: As far as I can tell, it's the browser that's blocking this request. Is this an Apache configuration issue?
Question #2: If I can fix the CORS issue, will the JavaScript be able to successfully interpret the response from the iDP such that mellon establishes a new session? I've been reading some articles that give me some pause - some people talk about potentially having to embed a hidden iFrame on the page to handle the iDP response prior to redirecting to the destination URL.

Sending JWT alongside html document in http response

How to send the JWT to a client just after client has authenticated without using Cookies when an html document body is needed to be sent too?
There are docs, blog posts, and tutorials, explaining the cookie-less jwt authentication and leveraging the use of Web Storage API to save the jwt client side. But all of them are trivial examples without sending an html document in http response body upon an authentication which is necessary in some real world applications I can imagine. A cookie can be sent in cookie http response header alongside with an html document in same response's body, I could not still come across a post explaining to do this with a jwt in response instead of a cookie. As I know there is not an API to reach the response headers from javascript in browser if one want to send the jwt in response headers alongside html document in response body.
I have handled your scenario in my project and it can be done in two ways depending on your technology stack you are using and environment constraints, and using OAuth is not mandatory.
Method 1
Send the JWT embedded in the HTML page as a tag. It wont be rendered on the page but can be parsed by you. However, it will be visible in the source window of the browser but it doesnt matter as that would be a protected page and once the next page is rendered, it will not be available.
Method 2
You can send the JWT in a cookie for the first time with a http-only constraint. Handling it over https would bring in extra leverage. Also, like you mentioned, you can delete the cookie.
In case you are using AngularJS on your client side, you have the provision of securing cookies by restricting XHR from the same domain which would avoid the extra task of deleting the cookie.
In fact, #user981375 was mentioning about redirection which can be handled too by Method 1 above. In my case, server provided the redirection URL after successful login however, ajax wouldnt be able to see a 302 header instead would see a 200. So we intercepted that part on server and embedded the token into the 200 response page, i.e. redirected page which is parsed by the client.
I'm in the same boat, I could not figure out how to send JWT token to the client upon successful (or not) social login(s) where redirect was required. Things are simple when when you present user with a login/password and authenticate against your own server via AJAX, but no so simple when you 1) load your login page, 2) do a redirect to OAuth provider, 3) callback to your own server, 4) issue your own JWT token and ... then what?
There is a library out there that provides OAuth support from the client side. You authenticate against Facebook/Google (whatever) get their token back and then you make AJAX request to your own server for token validation. When token is validated by Facebook/Google (whatever) you can then issue your own JWT token with claims and send it as a response (AJAX) to your webpage.
Here is the library and nice article describing how to use it.
HTML documents are usually retrieved from a web application. Web applications are protected by a form of implicit authentication.
Web APIs are usually protected by explicit authentication and the JWT tokens are sent in an HTTP header (Authorization). This is not done automatically by the browser. You have to do this explicitly through JavaScript.
You could of course store the JWT token in a cookie and have it automatically sent to the server on each request.
See also my answer here.

Reddit OAuth2 User Authentication

I am working on a web app which requires a user to login to their reddit account and according to https://github.com/reddit/reddit/wiki/OAuth2#retrieving-the-access-token I need to send a POST request to https://www.reddit.com/api/v1/access_token with some parameters. I am currently running the server from localhost and I keep getting the error:
XMLHttpRequest cannot load https://www.reddit.com/api/v1/access_token. Request header field Access-Control-Allow-Origin is not allowed by Access-Control-Allow-Headers.
I was struggling with this same issue and figured out that I need to register my app as "Installed" instead of "Web". This will make the authorization redirect with the bearer token instead of the code.
http://wattydev.com/authenticating_a_js-based_reddit_application_with_user_login_%28implicit_grant_flow%29

Categories

Resources