So I have a wildcard host on an Apache Server using mod_auth_openidc
The relevant bits of my Apache config are:
<VirtualHost *:443>
ServerAlias *.sub.mydomain.com
OIDCRedirectURI https://sub.mydomain.com/oauth2callback
OIDCCookieDomain sub.mydomain.com
Is there anything that would prevent a user from authenticating with foo.sub.mydomain.com, then also being authenticated with bar.sub.mydomain.com without having to log in again?
No, that works since the session cookie is set on sub.domain.com and as such received on foo.sub.mydomain.com as well as bar.sub.mydomain.com.
What you describe in the comment is not really an attack since it is the same user in the same browser. Sort of the equivalent of what is mentioned above, except handled manually in the browser... It would be a problem is you could somehow steal a cookie from another user but then again that would be an attack not specific to mod_auth_openidc and is impossible assuming everything runs over https and there's no malware in the browser.
If you really need separation you can split out in to virtual hosts and run a different mod_auth_openidc configuration in each host. Then the Apache cookies won't be reusable across the two hosts. Of course both hosts would still redirect to the OP for authentication and an SSO session+cookie may exist there that binds the two sessions together implicitly.
Related
I'm new to IdentityServer4 (2.5) and certificate setup so please bear with me. I think that I've chased down everything I could. I am using it with ASP.Net Core 2.2.0 in a proof of concept app. I have OpenIdConnect with an authority app and a client using cookies with X509Certificate2. Works great on my local machine; however, when I deploy to IIS I get this error:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://my.com/mpauth/.well-known/openid-configuration'. ---> System.ArgumentException: IDX20108: The address specified 'http://my.com/mpauth/.well-known/openid-configuration/jwks' is not valid as per HTTPS scheme. Please specify an https address for security reasons. If you want to test with http address, set the RequireHttps property on IDocumentRetriever to false.
The problem is here - http://my.com/mpauth/.well-known/openid-configuration/jwks. If I put that in the browser I get an error; however, if I change http to https I get the data. What setting controls this?
TL;DR
In most cases IdentityServer defers the base hostname/URI from the incoming request but there might be deployment scenarios which require enforcing it via the IssuerUri and/or PublicOrigin options as documented here.
More Info
The URL you are getting in your exception is part of the discovery lookup. It is necessary for validating tokens (e.g. in an applications auth middleware).
There should be a first request to .../.well-known/openid-configuration (the main discovery document) that refers to several other URIs and one of them should be the jwks (signing key sets). In most cases the other URIs in openid-configuration will point to the same primary hostname and protocol scheme your identity server is using. In your case it looks like the scheme changes to HTTP which might be unwanted in this day and age.
Is it possible, that the deployed IdentityServer lives behind a load balancer/SSL termination appliance? This could cause behavior.
I am not sure about IIS details but there might also be some kind of default hostname/URI thing at play.
I've a running Django app served on Google App Engine standard under a custom domain: mysite.com.
My site was running pretty well for days but suddenly it stopped serving content using the custom domain.
In summary:
www.mysite.com => works
mysite.com => stopped working
There were no changes in either the DNS nor the app deployment.
What I've tried:
First I checked the DNS lookup for these names:
a) nslookup my-app.appspot.com <== the GAE canonical site name
b) nslookup mysite.com <== custom domain FAILING, ip resolved
c) nslookup www.mysite.com <== custom domain working, ip resolved
d) nslookup ghs.googlehosted.com <== the recommended GAE DNS entry for www subdomain
Surprisingly not only all the names are resolved correctly but also they map to different IP addresses.
Actually, c) and d) map to the same IP (as expected). Anyway its not a DNS problem as stated here.
Second, I checked GAE settings to see the custom domain and tried to add another domain: mysite.com. But it claimed it was already mapped.
Third, according to this answer:
- I deleted the naked domain mapping and re-added later.
Fourth, I've checked documentation and don't find any missing thing in my setup:
https://cloud.google.com/appengine/docs/standard/python/mapping-custom-domains?hl=en#top_of_page
Both naked (mysite.com) and 'www.mysite.com' custom domains were working for days!
The current behavior is a bit weird. Running:
wget mysite.com
Produces:
Connecting to mysite.com (mysite.com)|xxx.yyy.zzz.ddd|:443... connected
Then it hangs for a while and ends with Unable to establish SSL connection.
The same happens using the web browser.
Anyone facing the same problem?
Any help is appreciated.
In case it is useful for someone else:
The problem has gone away suddenly, after an hour or so.
The only change I am aware of is to delete and register again the mysite.com custom domain entry in the GAE Web cloud console.
The naked domain is now working perfectly.
To avoid getting your site offline:
How to be alerted about your site's availability
Enable Stackdriver monitoring by entering into
https://console.cloud.google.com/monitoring
Create an uptime check using your site URL
In Policies: Create an alert policy to be notified by email or app push messages.
I have multiple domains directing to multiple directories on my system, as an example...
shopwebsite.co.uk > public_html/useraccounts/shopsite
carwebsite.co.uk > public_html/useraccounts/carsite
foodwebsite.co.uk > public_html/useraccounts/foodsite
This has been okay for a while until I realized that framed forwarding caused the mobile responsiveness to stop responding and so I changed all of the domains to simple redirects. This does work although as you can now work out, whenever somebody types in one of these URLs the website displays as something like:
https://mymainwebsite.co.uk/useraccounts/foodsite
Which is causing a few problems for me in various ways. What I am looking to achieve is to attach each domain to its directory path while keeping the URLs and being able to use the domain properly while also keeping mobile responsiveness.
Now this may seem like a really simple situation although I have a couple different domain hosts and my website hosting is via Hostinger, so I am not able to manipulate certain back end features, making it slightly more difficult for me. I am also still learning and really don't have much knowledge in DNS, IP forwarding, etc so I wouldn't know what I'm looking for?
If somebody can point me in the right direction I can more than likely figure the rest out on my own. I can access my htaccess file for the main website as well as DNS and ability to park domains etc...
Hope somebody can help me find a solution. Thanks.
I think you are looking for something called "Virtual Host". This is a configuration of the web server that allows you to run multiple web sites on the same server. In Apache simple virtual host looks like this:
<VirtualHost *:80>
DocumentRoot "/public_html/useraccounts/shopsite"
ServerName shopwebsite.co.uk
# Other directives here
</VirtualHost>
<VirtualHost *:80>
DocumentRoot "/public_html/useraccounts/carsite"
ServerName carwebsite.co.uk
# Other directives here
</VirtualHost>
There are no redirects in this method. The browser is connecting to the webserver and is sending "Host" header - the domain name typed in the URL, then it returns the files from the directory you configured in "DocumentRoot" directive for this "ServerName".
You should call your hosting provider support team and ask them how do you manage virtual hosts.
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property