For some reason IIS is not recognizing my Forms Authentication cookie, it keeps redirecting to the login page. The login page is ColdFusion 10 based using .NET integration. I've basically tried to mimic the "Creating the Forms Authentication Cookie" section of this MSDN article.
IIS 7.5 Authentication has Forms Authentication enabled with these settings:
Login URL: /my/login/page.cfm
Timeout: 30
Mode: Use cookies
Name: .CFAUTH
Protection: Encryption
Require SSL: No
Extend expiration: Yes
The code basically looks like this:
<!--- Authenticating code here... --->
<!--- Create .NET Instances --->
<cfobject type=".NET" assembly="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.dll" class="System.Web.Security.FormsAuthentication" name="authForm" />
<cfobject type=".NET" assembly="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.dll" class="System.Web.Security.FormsAuthenticationTicket" name="authTicket" />
<!--- Create Auth Ticket --->
<cfset authTicket.init(2, "user.name", Now(), DateAdd("n", 30, Now()), false, "") />
<!--- Encrypt the Ticket, Creating Cookie Value --->
<cfset authCookie = authForm.Encrypt(authTicket) />
<!--- Create the actual Cookie --->
<cfcookie name=".CFAUTH" expires="#DateAdd("n", 30, Now())#" value="#authCookie#" />
<!--- Redirect Back to Originating URL --->
<cflocation url="#URL.ReturnUrl#" />
I know everything with the code is working properly because the cookie is set in the browser and I can Decrypt() the cookie value and Get_Name() to retrieve the correct username. However, IIS just doesn't care about the cookie. Any thoughts? Am I missing something? Thanks for any feedback!
Check your cookies again. ColdFusion capitalizes cookie names, regardless of how you type in the name. Also verify the domains. I've had issues previously with mixing CF and .Net where cookies were involved. We ultimately tracked the issue back to the capitalization issues and the cookie domain.
Grab a cookie plugin for your browser. Those are invaluable when hunting down cookie issues.
Related
I need to run OWASP ZAP against one of our sites running on Netlify, but it is password protected (see screenshot for what I mean). For those who don't know how it works, when you visit the site, Netlify returns a 401 with the response of the request being the form. The form takes a password (input name is password) and POSTs it to the same URL (so https://myapp.netlify.app/ returns 401 and then the form POSTs it to https://myapp.netlify.app). I've created the context that should work, but I don't think it likes the 401 being returned as the same URL as the POST.
I'm sure I'm just doing a really stupid thing, but here is the relevant snippet from the config:
<authentication>
<type>2</type>
<strategy>EACH_RESP</strategy>
<pollurl/>
<polldata/>
<pollheaders/>
<pollfreq>60</pollfreq>
<pollunits>REQUESTS</pollunits>
<form>
<loginurl>https://myapp.netlify.app</loginurl>
<loginbody>password={%password%}</loginbody>
<loginpageurl>https://myapp.netlify.app</loginpageurl>
</form>
</authentication>
I also tried this snippet, in case it required the username (the UI kept enforcing the use of username):
<authentication>
<type>2</type>
<strategy>EACH_RESP</strategy>
<pollurl/>
<polldata/>
<pollheaders/>
<pollfreq>60</pollfreq>
<pollunits>REQUESTS</pollunits>
<form>
<loginurl>https://myapp.netlify.app</loginurl>
<loginbody>username={%username%}&password={%password%}</loginbody>
<loginpageurl>https://myapp.netlify.app</loginpageurl>
</form>
</authentication>
School boy error. I had everything configured properly, but wasn't providing the user (I thought the forced user would be picked up).
Running zap-baseline.py -t https://myapp.netlify.app/ -r testreport.html -n /zap/wrk/myapp.context -U testuser works.
The issue I have is we currently are using IdentityServer as our SSO authentication for our corporate applications. However, the bulk of our applications are under the same Site ID in IIS 7.5. When navigating to more than 5 of these applications under the same Site ID, you end up getting a 400 error, request header too long. The reason being each application has its own cookie, so the request header is passing around 5+ cookies with token information and the becoming too large.
My question is, are you able to prevent the sharing of cookies between applications under the same Site ID in IIS 7.5?
We also have IdentityServer for SSO and internal applications hosted on the same machine on IIS.
And I faced with the same problem too.
Here is a solution:
1) You need to solve Owin/Katana middleware problem to avoid nonce overfloating. Here you can find the code for that fix
2) You have to stop sharing cookies.
So if your base address for applications is "mysite.com".
And you have a lot of different applications like this:
Good App: mysite.com/good_app/
Best App: mysite.com/best_app/
Super App: mysite.com/super_app/
Use CookiePath for each application on an application's side and it will limit cookies (and look here too).
Use the code like this (for "Good App"):
var cookieOptions = new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = "GoodAppCookies",
// Cookie Path same as application name on IIS
CookiePath = "/good_app
};
Hope it'll help.
Few things that you can try. Make the following changes at the server level.
Highlight the server name in IIS, select "configuration editor", select "system.web" and "httpRuntime" and change "maxRequestLength" to "1048576".
You can also edit the "applicationHost.config" file in the following way- C:\Windows\System32\inetsrv\Config
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
Edit "Request Filtering" settings at server level on IIS and set "maxAllowedContentLength" to "1073741824"
You can also edit the root web.config file in the following manner - C:\Windows\Microsoft.NET\Framework64*\v4.0.30319*\Config
*Folder is based on your application. if its a 32 bit application, navigate to "Framework" folder. If its a .net 2.0 application, navigate to v2.0.50727.
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
First of all - I want to say that I have not tried this myself, so I can't assure that it is a solution, but I'm trying to help.
The problem with the cookies originates from the Microsoft OWIN/Katana and the way they are encrypting them. They become enormous, but this has nothing to do with Identity Server. However here and here there are good discussion around this.
The main thing to try first is in the Startup.cs of the IdentityServer project, in the IdentityServerOptions.AuthenticationOptions there is a property SignInMessageThreshold which defaults to 5. Try setting it to something lower, this will keep your header smaller (which may cause round trips to identity server when an app doesn't have its message in the cookies, but this will not force the user to re-login).
Another thing, that we achieved in one of out projects, is to create a DataBase backed cookie session handler. In your clients, where you use
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = cookieName,
});
There is also a property SessionStore. You can have a custom implementation of the Microsoft.Owin.Security.Cookies.IAuthenticationSessionStore. In our case this reduced the cookie size to less than (or around) 300.
My ACS URL is being rewritten from https://foo.com/ to http://foo.com/ which is causing the below Exception.
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.AssertionConsumerServiceUrlDoesNotMatchPolicyException: MSIS3200: No AssertionConsumerService is configured on the relying party trust 'foo-shibboleth-sp' that is a prefix match of the AssertionConsumerService URL 'http://foo/Shibboleth.sso/SAML2/POST' specified by the request.
The log message reflects that the auth request was sent as http as well:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://foo/Shibboleth.sso/SAML2/POST"
Destination="https://bar/adfs/ls/"
ID="_12345ID" IssueInstant="2017-08-08T22:24:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"><saml:Issuerxmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">foo-shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>
2017-08-08 22:24:28 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: message encoded, sending redirect to client
I have included my configuration below.
The SP metadata I've configured in my IDP has the correct URL with https, but is being changed to http somewhere downstream and can be seen in the Shibboleth logs for the samlp auth request.
If I switch handlerSSL to TRUE, the ACS URL in the samlp auth request shows https. However, when it's set to TRUE, anything at the path of /Shibboleth.sso/ such as /Status, or /SAML2/POST are 404ing.
I should also note that this is actually a site migration and this was all on windows in a datacenter now it's on Linux in AWS. There could be an issue with the Load Balancer where we terminate SSL, but haven't been able to debug that.
In the SP metadata that was provided to the IDP, I specify the https /SAML2/POST url. There is a bunch of config here, but I tried to highlight the relevant stuff.
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_97e389f1c212...." entityID="foo-shibboleth-sp">
...
<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://foo/Shibboleth.sso/Login"/>
....
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://foo/Shibboleth.sso/SAML2/POST" index="10"/>
Then, in the shibboleth2.xml on my SP, I have the following application override config:
<ApplicationOverride id="lms" entityID="foo-shibboleth-sp"
homeURL="/path/to/sso/location">
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="false"
exportLocation="https://foo/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
idpHistory="false" idpHistoryDays="7">
<!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="http://bar/adfs/services/trust">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>
</Sessions>
<MetadataProvider type="XML" file="/etc/shibboleth/metadata-sp.xml"/>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" path="/etc/shibboleth/attribute-map.xml"/>
</ApplicationOverride>
Finally, the only other piece that I have determined could be causing issues, is the IDP metadata here:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_1234-..." entityID="http://bar/adfs/services/trust">
...
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" index="0" isDefault="true" />
....
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://bar/adfs/ls/" />
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://bar/adfs/ls/" />
apache config also, though it seems pretty cookie-cutter
<Location />
ShibRequestSetting applicationId lms
</Location>
<Location /path/to/sso/location>
ShibRequestSetting applicationId lms
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>
The problem ended up being related to SSL Offload with the AWS Load Balancer. Because we were terminating at the ELB, we needed to set https:// on the ServerName directive in Apache config so that it would generate the https self-referential urls.
http://httpd.apache.org/docs/2.2/mod/core.html#servername
Need help on sharepoint 2013 Rest API with Ajax Call.
I am trying to read the list items from publishing site to the team site. Both the sites are in different site collections.
The below code is worksfine in Internet explorer and not in Google chrome.
$(document).ready(function() {
$.support.cors = true;
$.ajax({
url:"http://icon.heart.com/WorkTools/Organization/Claim/_api/web/lists/getByTitle('Claims Links')/items?$top=200",
type:"GET",
headers:{"accept":"application/json;odata=verbose"},
dataType: "json",
success: function(data){ alert("pass")}
error: function(Data){ alert ("Fail");}
});
});
The response had Http Status code 401. The error from the $.ajax request is
Failed to load resource : the server responded with a status of 401(unauthorized)
Error 2:
XML HttpRequest Cannot load No 'Access-control-Allow-Origin' header is present on the requested resource. Oringin 'url' is therefore not allowed access.
I don't have access to the servers. I need to try only with Script editor on SharePoint 2013 page.
Most likely it occurs since Chrome refuses to set a an Origin header for a CORS request. It won't even let you explicitly override the Origin header. Basically this causes the server to see Origin: null, which results in a 403 in most cases. IE/Firefox apparently has no such constraint.
As a workaround in case of SharePoint On-Premises you could set a custom header in web.config:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
or specify explicitly domain:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://anotherintra.contoso.com" />
</customHeaders>
using OOB scripts, it will not be fixed. the changes need to be done at server side as specified by Vadim Gremyachev. Also it might work in IE8 but in IE10 it will show you a security pop up asking for accessing data from other domain.
headers: {
"Accept": "application/json; odata=verbose",
"X-RequestDigest": $("#__REQUESTDIGEST").val()
},
As explained in Work with __REQUESTDIGEST, some requests require to add the request digest. Even, if this is a get request and the explanation on the ms pages is for "non-GET" requests, it solved some unauthorized issues with my api SP GET calls too.
It is possible the reason IE works and Chrome does not is due to how the respective browsers handle your credentials. To provide your credentials in chrome add the following code to your $.ajax call.
xhrFields: {
withCredentials: true
},
see
Cross domain ajax call windows authentication working in chrome and not working in Firefox
Sending credentials with cross-domain posts?
I have an application that uses Spring Security 3 runs on Tomcat. I didn't define any favicon for my website however when I run my application from my IDE sometimes after I login from my login pages it redirects my page to:
http://localhost:8080/favicon.ico
and says:
404 Not Found
There is a topic here: http://forum.springsource.org/showthread.php?100901-redirect-to-favicon.ico however I didn't define a favicon.ico does Spring Security 3 wants it by default(if yes, why it happens sometimes?)
Here is the explanation:
The issue is, when the browser cache is empty and a user comes in,
here is what happens:
the user requests URL "/". This URL is cached.
the browser makes a requests to "/favicon.ico". This URL becomes
the new URL where to redirect to upon authentication.
the user posts the login form and is redirected to "/favicon.ico".
To fix this, you need to set "/favicon.ico" as being a non-secured
resources:
<intercept-url pattern="/favicon.ico" access="ROLE_ANONYMOUS" />
Taken from: http://blog.idm.fr/2010/09/spring-security-redirecting-to-faviconico.html
For Grails 3.0.11 & Spring Security Core 3.0.2, add "IS_AUTHENTICATED_ANONYMOUSLY" in application.groovy in the section:
grails.plugin.springsecurity.controllerAnnotations.staticRules = [
...
..
.
[pattern: '/favicon.ico', access: ['IS_AUTHENTICATED_ANONYMOUSLY']]
]