I'm trying to implement an OpenId provider using DotNetOpenAuth. I'm using their 2 samples together, an MVC replying party and an MVC provider.
Provider hosted at: http://localhost:4864/OpenId/Provider
Relying hosting: http://localhost:54347/User/Login
I tried it with google (https://www.google.com/accounts/o8/id), and I got authenticated. When I tried http://localhost:4864/OpenId/Provider. The relying party said no openId endpoint was found. When I set a breakpoint on the provider, this code returns null:
IRequest request = OpenIdProvider.GetRequest()
So the comment for when request is null is this: No OpenID request was recognized. This may be a user that stumbled on the OP Endpoint.
So I guess my problem is at the provider end. What do I need to do to fix this?
in the dotnetopenauth sample, when the login screen asks for a provider and you want to use the sample mvc provider, the identifier to use in your case will be http://localhost:4864/
and not http://localhost:4864/OpenId/Provider
For me, I was using the sample MVC provider. Its HomeControllerhad the [Authorize] attribute. This meant the xrds request failed and so an exceptions 'Sequence contains no elements' and 'No OpenID endpoint found' were reported. Removing the [Authorize] attribute allows the xrds request to succeed and you can log in to a site being debugged in one instance of Visual Studio using OpenID from a site being debugged in another instance of Visual Studio.
For security reasons, DotNetOpenAuth RP defaults to disallowing OpenIDs that start with http://localhost/. For your testing purposes you can whitelist localhost so that it works for you:
<dotNetOpenAuth>
<messaging>
<untrustedWebRequest>
<whitelistHosts>
<!-- since this is a sample, and will often be used with localhost -->
<add name="localhost" />
</whitelistHosts>
</untrustedWebRequest>
</messaging>
</dotNetOpenAuth>
Related
I am working on MVC framework in ASP.NET where, I was trying to access the application but I was not able to go past the login screen, after which it kept throwing the not found IIS error. After workaround i found that i had this line : httpCookies httpOnlyCookies="true" requireSSL="true" in my web.config file which was stopping the access. Can anyone help me understand the problem and concept here?
Thanks already.
I was able to access the site after removing the requireSSL part only.
Web-config
httpCookies httpOnlyCookies="true" requireSSL="true"
Global.asax's Application Start :
if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Tls12) == false)
{
ServicePointManager.SecurityProtocol =
ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12;
}
I think the part of code in global.asax's Application Start might be causing the problem, but I'm not sure about it.
Websites use cookies to store information between page requests or browsing sessions.
The callback from an external provider to your site contains security tokens(httpCookies) that allow access to your site and contain user information.
If someone manage to steal other's authentication cookie for a website, he could carry out all the actions that they are capable of.
Transmitting this information over HTTPS to prevent interception while this information travels over the Internet is important
You can stop script access to all cookies in your site by adding a simple flag: HttpOnly. You can set
this flag in the web.config, as follows:
<httpCookies domain="" httpOnlyCookies="true" requireSSL="false" />
So If you write requireSSL="true" in your Web.config It Enforcing the external provider to make their callbacks to your site using HTTPS only.
#Vishesh Pandita In your case you are trying to access site using HTTP only. So faced "HTTP Error 403 - 403.4 Forbidden: SSL required" error.It means the page you are trying to access is secured with Secure Sockets Layer (SSL).
Solution:
To view the page, you must enable SSL (Secure Sockets Layer) by typing "https://" instead of "http://" at the beginning of the address you are attempting to reach. The "s" in "https" specifies a secure site.
Migration for HTTP to HTTPs
source : Professional ASP.NET MVC 5
I have a webapplication using spring security. I'd like to login using an account i have configured on the WSO2 identity server using OpenID.
I can login just fine, the identity server asks for the password and redirects me back to my webapplication. So far, so good. However, when i try to request additional attributes using the attribute-exchange, i get empty values.
I have tried a few different types:
schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
axschema.org/namePerson/first
urn:scim:schemas:core:1.0:name.givenName
schema.openid.net/2007/05/claims/nickname
wso2.org/claims/givenname
But none of them seem to yield any results.
Am i missing something obvious?
The reason may be the fields are empty as well.
Can you try with the following claim URI, http://wso2.org/claims/role. By default all users have the everyone role. So that value should be returned.
I have an MVC 4 application receiving SAML2 tokens from an initiating IdP. I can see the token as it arrives and I can decrypt it. However, I want to do this with WIF 3.5 and seem to be having problems with SAML Namespaces when I try to use the WSSecurityTokenSerializer as follows:
System.Xml.XmlException was unhandled by user code
HResult=-2146232000
Message=Cannot read the token from the 'Response' element with the 'urn:oasis:names:tc:SAML:2.0:protocol' namespace for BinarySecretSecurityToken, with a '' ValueType. If this element is expected to be valid, ensure that security is configured to consume tokens with the name, namespace and value type specified.
Source=System.ServiceModel
LineNumber=0
LinePosition=0
StackTrace:
at System.ServiceModel.Security.WSSecurityTokenSerializer.ReadTokenCore(XmlReader reader, SecurityTokenResolver tokenResolver)
at System.IdentityModel.Selectors.SecurityTokenSerializer.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
at SamlHandlingTests.SamlTests.TestMethod1() in g:\Projects\mytempesub\Solution\SamlHandlingTests\SamlTests.cs:line 112
InnerException:
I have seen a post here StackOverflow question but the final resolution of doing things directly with XML doesn't suit me because I need to be able to run this up as a standard IdP-Initiated solution.
Therefore I have two questions:
Has anyone ever managed to overcome this error with WIF? (I don't need the WIF Extensions as I am only concerned with handling SAML2 tokens, not protocol.
To use WIF in an IdP-Initiated environment I understand requires no configuration, I have simply set authentication off and I check the incoming token. However, I would prefer to check the token in the full WIF pipeline but this then needs configuration. How can I configure WIF to function in this IdP-Initiated environment?
Many thanks
Brian
If you need to deserialize the token you might consider instead using Saml2SecurityTokenHandler.
I would also ask, does your scenario require you to deserialize the token yourself? WIF integrates well with ASP.NET MVC applications so you might instead rely on the WIF to do this for you. See Eugenio's answer here.
I have two servers: STS and Web. On the STS server, I call:
FormsService.SignIn(model.UserName, false);
The next line, I check:
User.Identity.IsAuthenticated
This is set to TRUE. Then I redirect back to my Web server and in the controller I hit, I check:
User.Identity.IsAuthenticated
This is set to FALSE.
What could cause this?
UPDATE: I also just tried moving the STS web site to the Web server. I get the same error/issue
UPDATE: I forgot to mention that our DEV server works just fine. The configuration there is identical (except for the server name and cert thumbprints). The only thing different between these two servers is that one (DEV) is using a self-signed cert and is inside our firewall. The other (QA) is using an official (thawte) cert and is ourside our firewall. This cert's common name does not match the server name (so it can be shared in our farm). So when we access the site, we do so using https://[commonname].com/web as opposed to https://[servername]/web. I tried the latter approach (I get cert errors that there is a name mismatch) but still have the same result.
Also, I can access the STS site directly and login fine there.
ASP.NET authentication is based on cookie by default. Cookie lives inside web domain.
So if you have two servers installed like this:
http://www.web.com
http://www.sts.com
WEB server cannot read cookie set by STS
There are two possible solutions:
Implement both servers as sub-domains
Store authentication ticket in URL instead of cookie
For option 1
Move servers as follows:
http://www.web.yourdomain.com
http://www.sts.yourdomain.com
Update web.config to scope cookie to yourdomain.com:
<authentication mode="Forms">
<forms domain=".yourdomain.com"/>
</authentication>
For storing ticket in url check this article - http://www.codeproject.com/Articles/2796/Cookieless-ASP-NET-forms-authentication
Update: Seems that I did not get that STS stands for Security Token Service. My answer is not relevant. :(
While redirecting from your STS server you will have to redirect using the AutoPostform which will submit the token to the Relying party.
And when Relying party will receive the token it will create the cookie against that user.
So next time whnen you will check User.Identity.IsAuthenticated at Relying party it will return you True.
Go throung the following link to know more,
http://chris.59north.com/post/2013/03/27/Claims-based-identities-in-ASPNET-MVC-45-using-the-standard-ASPNET-providers.aspx
We had the same issue when moving the RP to a different server. It turns out that we needed to go into the application pool -> advanced settings -> Set 'Load User Profile' = true.
After that, everything worked as it should on the new server and User.Identity.IsAuthenticated was returning 'true' after it came back from the STS.
I have implemented a SAML Service Provider to support Single Sign On for an ASP.Net web portal, which is a shrink-wrap software configured on clients' sites and must be able to interact with any SAML-compliant Identity Provider.
My Assertion Consumer Service (ACS) page will accept the SAML Response through both GET and POST methods.
As I understand the SAML protocol, the SAML Request ProtocolBinding property specifies which protocols are supported for the response. Currently, my request specifies the HTTP-Redirect binding. However, I would like to declare that I support both HTTP-Redirect (GET) and HTTP-POST (POST). After searching through more SAML documentation than I care to reiterate, I am unable to find the syntax for declaring multiple supported protocol bindings (or whether it is even valid to do so).
While I could make this declaration configurable, my preference would be to declare both bindings so that the Identity Provider will work without additional configuration of my portal.
Below is a sample of my Authentication Request. Please, if anyone knows a way to declare both HTTP-Redirect AND HTTP-POST for the ProtocolBinding, I would greatly appreciate your input!
<?xml version="1.0" encoding="utf-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="[AUTHN_ID]"
Version="2.0"
IssueInstant="[ISSUE_INSTANT]"
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
ProviderName="[PROVIDER_NAME]"
AssertionConsumerServiceURL="[ACS_URL]">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
PortalEntityID
</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
</samlp:AuthnRequest>
Thanks in advance to anyone who can help!
The ProtocolBinding attribute on AuthnRequest is used to specify the expected binding to be used by the IdP when sending their SAML Response XML. HTTP-Redirect isn't a valid option to use here, because of the possible length restriction on the URL querystring; a SAML Response, especially if it's signed, can be pretty lengthy. I'll quote from the SAML spec [SAMLProf]:
...the identity provider issues a <Response> message to be delivered by the user agent to the service provider. Either the HTTP POST or HTTP Artifact binding can be used to transfer the message to the service provider through the user agent. The message may indicate an error or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be used, as the response will typically exceed the URL length permitted by most user agents.
After considerable research, it seems that you can only declare one Protocol Binding in a single SAML request.