I have a Spring Security app that uses SAML. It is working fine. I go to a secured page, I get redirected to the IDP, login... success.
Now I want to have the login done "in house" as it were, with no redirection.
I want to have a login page that takes username/pass - then -- well I don't know. :)
Is there anyway to NOT have the user's browser go to the IDP, either POST the form to the IDP and then redirect back to my app?
I read in the documentation about back-channel SOAP calls, and that sounds like exactly what I want, but I can't find anything on it. Does anyone have an example of how this would be achieved?
Related
I am working on Ruby on Rails application. I need to implement Single Sign on / Single Log out (SSO / SLO) using OneLogin.
I used OneLogin-Ruby-Sdk => https://github.com/onelogin/onelogin-ruby-sdk to log user via session token API. It creates a cookie in browser and allows me to login on other apps. But when I logout using log_a_user_out Api. It only logs out of current application but not from all applications. So SLO is not working in this case.
Thereafter, I integrated devise_saml_authenticatable => https://github.com/apokalipto/devise_saml_authenticatable. It works with SSO / SLO perfectly. But it redirects to oneLogin UI to generate SAMLRequest and send back SAMLResponse.
Is there a way I can generate SAMLRequest and SAMLResponse programatically ?
Just like we do for OAuth2 where we can generate access token using refresh token again and again.
Basically I want users to signup and login through my app forms and communicate with OneLogin and implement SSO / SLO using API rather than going to oneLogin UI.
Please let me know if more information is required in terms of code which could help in providing answer. I will be more than glad to do so. Any help is hugely appreciated.
I'm researching on SSO but there is one thing I coudn't understand is how SSO consumer can get session without clicking on Login Button. I can explain the case as below:
I have:
accounts.domain.com (Identity Server. Already Allow consumer 1 & 2)
myapp.com (Consumer 1)
yourapp.com (Consumer 2)
When I go to myapp.com -> I have no permisson or no session to access the server resources.
I click on Sign In button in myapp.com, this will redirect to accounts.domain.com and after authenticated, I get back to myapp.com with my local session.
The question is: When I go to yourapp.com, I already have session without click on Sign In button.
The real case is google.com, accounts.google.com, youtube.com, ...
I don't know how it works and how to implement this?
And one more question, Can I use Auth0 or Google Cloud Identity or AWS Cognito to build my Identity Provider like google did?
Can someone support me in this?
To better understand the concept u should 1st know what happens when u use SSO login.
I will take google and YouTube as examples.
When u login to google using your credentials u will not only get a local session but a single sign on token. We generally have this as SAML which is security assertion markup language token.
This SAML token will be stored in your client or browser in this case.
Now when u try to load youtube in the same browser this token will be sent to the IDP along with the request. Since the IDP knows that this user is already authenticated it will check for authorization for the particular website in this case YouTube, the page loads.
I have four custom apps (that are SPs), using Auth0 or OneLogin as my IdP. In Auth0 I create a connector for each application. When I login to one application and then open the other application, I get redirected to Auth0 to login again.
Is it possible to log the user into my IdP (or Auth0/OneLogin) automatically on that second app without having to click the login button on Auth0, since they've already authenticated with Auth0?
There is an unfortunate need to embed the second app into the first app and it's a poor UX to have the user login to the first app and then login again in the iFrame.
Auth0 Dev here, Yes this is supported Out of the box in Auth0, for this to work you'd have to turn Use Auth0 as IdP "ON" in your Client. When doing this Auth0 will then remember the client for 10 hours upto 3 days if the client is active.
The flow in your scenario will be
User logs in to any of the application.
User visits the other application.
The other application sees no session.
The other application redirects to /authorize endpoint.
Auth0 notices the session and redirects it back to your application immediately.
This is further detailed and explained at https://auth0.com/docs/sso
SSO is not having to re-enter credentials again but you only get SSO once you redirect to the IDP and you authenticate under the hood i.e. seamlessly.
So you still have to do something to trigger the redirect.
You could programmatically redirect to a dummy page that requires authentication that then redirects via your client stack e.g. OWIN OIDC.
Also, there is no standard for the cookies so you don't get SSO across multiple IDP unless they are federated together.
So if no federation and you login to Auth0, you will still have to login to OneLogin.
Looking at Google OpenId connect and Facebook login I noticed that Facebook always hits the "redirect URI" from the browser. To explain a bit more - when user follows link of the form
https://www.facebook.com/dialog/oauth?client_id={app-id}&redirect_uri={redirect-uri}
S/he is always redirected to the URL specified by {redirect-uri}. This URL then contains "code" which can be exchanged for access token.
Google has similar approach but when using "server-flow" the {redirect-uri} is "hit" by Google's servers. This way the code which needs to be exchanged for access token never gets shown to the user.
It seems like FB's approach is less secure as the access code can actually end up in the attacker's hands.
Is there a way to have FB send the code to a redirect URI but not actually redirect client? Something like what Google does.
Does anyone have a good explanation why FB does not have "server-flow"-like behaviour but only "implicit-flow"?
You should grab the code from the server then use it, together with your app secret, to exchange an access token on Facebook. It does not matter if the client can see this because without the app secret, that code is useless. And the app secret is kept on your server, it is never revealed to the client.
TL;DR version:
Can you authenticate with Facebook without having a callback URL for a web application since the web application isn't actually running on a server.
Full explanation:
I'm working on building a connectedTV platform application where the "app" itself is a bunch of HTML/JS/CSS running locally (like File -> Open on your desktop browser) and I'd like to integrate Facebook into this.
The problem is that all of Facebook's OAuth calls for the web require you to have a callback URL to redirect the user to in order to complete authentication. Here's the gotcha -- there is no URL for this application -- it's a locally running webpage on the device.
I know this is what out-of-band authentication was designed for, but I can't seem to find any documentation on how to use this (or how to do a non-callback OAuth flow) with the Facebook OAuth system.
You're describing desktop authentication or any situation where you are authenticating to FB without a server. The redirect URL you pass to the OAuth dialog is https://www.facebook.com/connect/login_success.html When the browser redirects you can get the access token. You can read all about it in the FB documentation, way at the bottom in the Desktop Apps section (https://developers.facebook.com/docs/authentication/)
Just reread your question and since the application runs inside a browser you will need to open another window to authenticate and get the access token from that.
If you're doing HTML/Javascript, use their Javascript SDK. You can log the guy in simply by using FB.login and getting the access token from the callback from that.
I really don't think this is directly possible. Unless there is something totally undocumented, Facebook has no mechanism to send authentication data except by loading a url. I'm sure it's meant at least partly as a security measure, functioning as sort of a "whitelist" of where auth data will be sent.
The only way I can think of for you to work around it might be to set up a url on a server somewhere that could answer the redirect and store the auth data, and have your client-side code poll that server to get it. Kind of a proxy authentication service, in effect. You would probably have to open a second browser window with the Facebook auth screen in it, but in theory it could work.