In our topography we have foo.com, myfoo.com, outletfoo.com and auth.idsrv.com.
For dev purposes, these are separate websites that live under 1 iis instance.
foo.com, myfoo.com and outletfoo.com are relying parties of auth.idsrv.com.
If user bookmarked any link in foo.com, myfoo.com or outletfoo.com and that link points to a resource requiring authentication, we redirect to auth.idsrv.com.
foo.com, myfoo.com and outletfoo.com are not https by default, one or more could be though. auth.idsrv.com is https.
After redirecting to auth.idsrv.com, I enter username/password all is well.
cookie “idsrvauth” is expiry Session / http. However, upon redirect back, the idsrvauth cookie is gone because of expiry Session.
Perhaps only my configuration is incorrect.
With foo.com, myfoo.com, outletfoo.com and auth.idsrv.com being separate domains, is there a supported scenario in the identity server configuration where relying parties can be separate domains? Can you point to the correct way to configure the relying parties so that each can receive the idsrvauth cookie.
When authentication is validated and the redirect happens, how would we have knowledge of the idsrvauth cookie in any (essentially cross domain) calling application in our example topography?
IdSrv uses WS-Federation for authentication. WS-Fed does not rely on cookies but sends a SAML token via a form post to the relying party (see the spec: http://msdn.microsoft.com/en-us/library/bb608217.aspx)
So in other words - cross domain is absolutely supported.
Related
I'm currently playing around with SignalR and websockets. From my research, it seems, as websockets do not support custom headers, there's basically only two ways to authenticate a websocket connection during token based authentication.
1) Passing the token in the query string
2) Storing the token in a cookie which then gets passed to the server when WithCredentials is set to true
The first method isn't great practice - even through websocket communication is encrypted, query strings may be logged by servers etc.
The second method I have got working on my local machine but it doesn't work once deployed because my client and server reside on different domains. So basically, I have an Angular site that has one domain (eg. client.com) and a WebAPI site that alls CORS with a completely different domain (eg. server.com). On my browser, if I'm on client.com, I cannot set a cookie that gets sent to server.com on a request.
What is a good way to authenticate websockets when client and server sit on different domains?
The WebSocket Protocol specification doesn't specify any particular way for authentication. You need to perform the authentication during the handshake phase and for that you can use any HTTP authentication mechanism like Basic, Digest, etc.
Further you could look into JWT token based authentication. Angular app can store the token in local storage and send it as a Transport header during the handshake request to the server. If the token is invalid, server can terminate the WebSocket connection upgrade request and the Angular app can re-direct the user to login page.
I am trying to implement third party authentication with openAM, and have a doubt regarding openAm implementation, i.e if my application is distributed under different servers which are geographically separated and controlled under the same DNS name. How can I differentiate the sessions of different server. Say for example if I type www.google.com it can forward to any of the nearest server available, now if I have to authenticate google.com how will my openAm know that the request is for that particular server. If I ask it in other way, so whenever we are changing a policy in openam or invalidating a session it callbacks to all the registered server, now in distributed environment how it can differentiate the server IP's
I assume you have some sort of LB in front of you servers. I would suggest creating a sticky session at the LB, like a cookie saying what server the user is on before starting the authentication. Then when authentication i done, openam redirects back to your LB and the LB directs to the correct server.
I am writing an HTTPS web server using express.js. It does not have super secure, I think ssl certificates is overkill and not a good option for client apps. I have routes for my restAPI. There will be a login page. So I will have a user/password pair available to me.
Can I use this information alone to allow access to my HTTPS routes ?
I think you're asking whether basic auth over https is secure. The answer is yes, that's a reasonable security architecture, and is widely used for authenticating APIs. It's fine to route based on the basicAuth credentials. If you start worrying more about security, focus on how to safely store passwords.
If I authenticate my clients using SSL client certs, is that necessarily a site-wide filter, or can I either require or not require authentication per-URL from within an application? So I'd like
https://mysite.com/my_url doesn't care who the client is, just uses 'normal' https
https://mysite.com/my_sensitive_url requires that the client is using a valid client cert
I'm working in Ruby on Rails, but I'm interested in the general question of whether SSL client cert authentication is flexible enough for this. I can imagine that a hand-written apache conf with different settings for different URLs could probably do it, but I'd really much rather define this kind of thing at the application level.
You would (a) set the server to do authentication via SSL certificates; (b) set the server to to 'want' rather than 'need' SSL client authentication, and then (c) define access rules for the specific URLs or patterns that required the user to be logged in, and not for the others.
I setup my own open id provider on my personal server, and added a redirect to https in my apache config file. When not using a secure connection (when I disable the redirect) I can log in fine, but with the redirect I can't log in with this error message:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
I'm guessing that this is because I am using a self signed certificate.
Can anyone confirm if the self signed certificate is the issue? If not does anyone have any ideas what the problem is?
The primary benefit of using SSL for your OpenID URL is that it gives the relying party a mechanism to discover if DNS has been tampered with. It's impossible for the relying party to tell if an OpenID URL with a self-signed certificate has been compromised.
There are other benefits you get from using SSL on your provider's endpoint URL (easier to establish associations, no eavesdropping on the extension data) which would still hold if you used a self-signed cert, but I would consider those to be secondary.
OpenID is designed in a redirect-transparent way. As long as the necessary key/value pairs are preserved at each redirect, either by GET or POST, everything will operate correctly.
The easiest solution to achieve compatibility with consumers that do not work with self-signed certificates is to use a non-encrypted end-point which redirects checkid_immediate and checkid_setup messages to an encrypted one.
Doing this in your server code is easier than with web server redirects as the former can more easily deal with POST requests, while also keeping code together. Furthermore, you can use the same end-point to handle all OpenID operations, regardless whether or not it should be served over SSL, as long as proper checks are done.
For example, in PHP, the redirect can be as simple as:
// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
($_GET['openid_mode'] == 'checkid_immediate' ||
$_GET['openid_mode'] == 'checkid_setup'))
http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");
As the openid.return_to value was generated against a plain HTTP end-point, as far as the consumer is concerned, it is only dealing with a non-encrypted server. Assuming proper OpenID 2.0 operation with sessions and nonces, whatever information passed between the consumer and your sever should not reveal exploitable information. Operations between your browser and the OpenID server, which are exploitable (password snooping or session cookie hijacking) are done over an encrypted channel.
Aside from keeping out eavesdroppers, having authentication operations be carried out over SSL allows you to use the secure HTTP cookie flag. This adds yet another layer of protection for checkid_immediate operations, should you wish to allow it.
(Disclaimer: I'm new to OpenID, so I might be wrong here.) The communication between the Open ID Consumer (e.g., StackOverflow) and the Open ID Provider (your server) does not require HTTPS -- it will work just as fine and just as securely over plain HTTP. What you need to do is to configure your server to switch to HTTPS only when it shows you your login page. In that case, only your browser needs to concern itself with the self-signed certificate. You could import the certificate onto your PC and everything will be as secure as with, say, Verisign-issued certificate.
It sounds like it. The client of your OpenID server doesn't trust the root certification authority.