I'm using spring security oauth with stateless sessions. But my problem is the spring is using SPRING_SECURITY_SAVED_REQUESTS to save the source URL to which it has to redirect to after a successful login and it is maintained in the session. Since I m using stateless session I'm always being redirected to "/".
The same exact issue as in the post below
Redirecting to original URL for stateless session
Did anyone found a solution for this issue?
Related
I were following the sample provided in OneLogin Developer Portal - https://developers.onelogin.com/quickstart/authentication/java-spring. I did everything described in the article. But on running the application, authentication happens; I were taken to OneLogin page and I enters the credentials. But on redirection, I get following error.
"http://localhost:8081/login" is the redirect url configured in admin portal. And it is the default url which is been passed in the first request.
https://kore-wireless-dev.onelogin.com/oidc/2/auth?client_id=<?>&redirect_uri=http://localhost:8081/login&response_type=code&scope=openid profile email&state=UY6Tam
In the sample code, the endpoint is not implemented. But I don't think application developer needs to implement that endpoint.
I tried Github SSO. Where we can specify different redirect urls in app configuration (spring-security-url) and github sso configuration (app-url). And after authentication github will redirect to spring-security-url. And then that endpoint will redirect to app-url.
Is Spring Security OAuth2 is not compatible with OneLogin? Or what I am missing here.
I have recently faced the same issue. In my case, we had to modify the Authentication Method of the Token Endpoint in OneLogin oidc application. When it was set to Basic, it was throwing the Unauthorised error. Probably, the sample application invokes the OIDC token endpoint with credentials (clientID and clientSecret) in the payload request (POST Auth Method) rather than in request header(Basic Authentication method). Sharing the screenshot of the same here.
We have some problems hooking our single page application written in backbone to a SAML authentication.
So here's wat we have (based on http://developer.okta.com/docs/guides/saml_guidance#planning-for-saml)
- the SPA is loaded
- first request to the back-end (SP) results in response telling it to redirect the IDP
- then the browser is at the IDP page. Basically our SPA is gone
- IDP redirects with a POST after successful login. This post contains stuff our SP needs to decode to login
Now the trouble we have is that post must be directed into the SP (back-end) and thus our SPA is not loaded. If we redirect (302) to our SPA, we cannot send authentication cookies.
Am I missing something here?
Thanks for any pointers
We were obiously missing something. Our back end and front end were running on different nginx websites, with front looping through some parts to the back end. We had the IDP post back to a page on the backend domain, so the browser did not find any cookies on the front end domain.
Took us some time
Thanks!
I'm experimenting with moving an existing enterprise app to HTTP 2.0 at my customer's request. The app uses ASP.NET Forms Authentication, and when accessed over HTTPS with HTTP 2.0-aware browser and server (Windows Server Tech Preview), authentication appears to succeed during the login action, redirecting to the requested URL, but then the server responds to the next request with a redirect back to the login URL again. After adding some diagnostic logging to Application_BeginRequest, I found that the auth cookie is present in the request, but an attempt to decrypt the ticket with FormsAuthentication.Decrypt() throws an exception stating that there are non-base-64 characters in the cookie. I suspect this has something to do with HTTP 2.0 header compression, but I would have thought that this should have been handled transparently by IIS and that the headers should have been decompressed by the time my code executes. Has anyone else experienced this and know of a workaround? Happy to provide additional information if I left anything out.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).
Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.
The client is redirected back to a pre-configured url on our original http web app when done.
However, the customer is then asked to "re-login" again on our side which is undesired...
It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.
How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?
It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.
This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.
If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.
Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:
Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
You're looking for a Single Sign On solution.
It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at:
Windows Identity Foundation