I'm facing the following problem:
The IDP has not a valid URI in AuthnContextClassRef field, and the lib itfoxtec-identity-saml2 is throwing an error when I try to use the method:
binding.ReadSamlResponse(Request.ToGenericHttpRequest(), saml2AuthnResponse);
The error is:
ArgumentException: IDX13300: 'value' must be an absolute Uri, was: 'adumbstringthatsomeoneconfigured'
StackTrace:
Microsoft.IdentityModel.Tokens.Saml2.Saml2Serializer.ReadAuthenticationContext(XmlDictionaryReader reader)
Microsoft.IdentityModel.Tokens.Saml2.Saml2Serializer.ReadAuthenticationStatement(XmlDictionaryReader reader)
Microsoft.IdentityModel.Tokens.Saml2.Saml2Serializer.ReadAssertion(XmlReader reader)
Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadSaml2Token(string token)
ITfoxtec.Identity.Saml2.Saml2AuthnResponse.ReadSecurityToken(string tokenString)
ITfoxtec.Identity.Saml2.Saml2AuthnResponse.Read(string xml, bool validateXmlSignature)
ITfoxtec.Identity.Saml2.Saml2PostBinding.Read(HttpRequest request, Saml2Request saml2RequestResponse, string messageName, bool validateXmlSignature)
ITfoxtec.Identity.Saml2.Saml2Binding<T>.ReadSamlResponse(HttpRequest request, Saml2Response saml2Response)
Okta_SAML_Example.Controllers.LoginController.AssertionConsumerService() in LoginController.cs
+
binding.ReadSamlResponse(Request.ToGenericHttpRequest(), saml2AuthnResponse);
Exception:
System.ArgumentException: IDX13300: 'value' must be an absolute Uri, was: 'LoginXyzWTPRO_Extern'
at Microsoft.IdentityModel.Tokens.Saml2.Saml2AuthenticationContext.set_ClassReference(Uri value)
at Microsoft.IdentityModel.Tokens.Saml2.Saml2AuthenticationContext..ctor(Uri classReference, Uri declarationReference)
at Microsoft.IdentityModel.Tokens.Saml2.Saml2Serializer.ReadAuthenticationContext(XmlDictionaryReader reader)
I would expect that the AuthnContextClassRef is set by the RP in the Saml2AuthnRequest?
According to the SAML 2.0 standard it should be a URI. But the ITfoxtec Identity SAML library accept a string.
I'm not able to reproduce the error. Please add a stack trace for more debug information.
****** EDITED ******
The library only support to resive a URI based AuthnContextClassRef from the IdP. The AuthnContextClassRef is validated by the underlining .NET classes, which require an URI. But with good reason, the SAML 2.0 standard require it to be a URI.
From SAML 2.0: A URI reference identifying an authentication context class that describes the authentication context...
Related
I'm working on getting some Shelly Power products (API Documents Here) able to be called from a .NET 6 Minimal API application.
Following the Digest Authentication documentation from Shelly and the RFC 7616, I have an extension method for the HttpClient that basically takes an HttpRequestMessage for the URL http:///rpc/Switch.GetStatus?id=0. After setting the normal headers (Accept, User-Agent, etc.) for that HttpRequestMessage, it passes that HttpRequestMessage as a parameter to that extension method.
After passing the HttpRequestMessage to the extension method, it is cloned into a new HttpRequestMessage, with the content, version, and headers. After that, the first SendAync() call is made, and the 401 response is generated containing the WWW-Authentication header. After parsing out the realm, nonce, and qop, the rounds of hashing is done according to the specs. Shelly uses SHA256 instead of MD5 (as they should) but overall follows the standard for hashing. After this, the newly formed Authentication Header string is created and it is formatted as such:
Digest username="admin", realm="shellyplugus-083af2018b68", nonce="633e7ba8", cnonce=8724224, response="9B15CEBA6E5FD862271954AC2C40948D6237511B83748143FF763A0E76B1A346", algorithm=SHA-256
The following code is the creation of an AuthHeaderObject, the creation of the string above, and gets added to the cloned HttpRequestMessage (called "digestRequest" here):
var digestAuthHeaders = new DigestAuthHeader(
"Digest", realm, username, password, nonce, qop, clientNonce, "SHA-256");
var digestRequestHeader = digestAuthHeaders.DigestRequestHeader();
digestRequest.Headers.Add("Authorization", digestRequestHeader);
The 2nd SendAsync() passing the cloned request and completion option enum.
var authRes = await client.SendAsync(digestRequest, httpCompletionOption);
The issue after this is that I am still getting a 401 response. Not even getting another code indicating another issue. It is just acting like the same request has been made.
Should I forgo the cloning of the HttpRequestMessage and simply create a new one? Does anything immediately standout that is incorrect? I want to note that Shelly only specifies that Authorization string only contain the values included, it does not require uri, qop, opaque, and some of the others.
Looks like there is a direct way to do this by using HttpClientHanlder and setting the NetworkCredentials property, then passing the Handler to the HttpClient.
I've confirmed that I have permissions to perform the request.
According to amazon's Cloud Search Dev Troubleshooting Guide the error I'm experiencing is likely due to the .net sdk using the wrong api version. I don't see a way to specify the api version explicitely.
I want to avoid having to manually create the http request.
I want to make the request through the SDK.
I've tried all the available versions of the SDK and all of them give me this error.
I've also tried specifying the request properties in various combinations. Nothing works.
Can anybody give me direction as to how I can resolve this issue?
Expected behavior: return info for all index fields
Actual behavior:
error -
"Result Message:
Amazon.Runtime.AmazonUnmarshallingException : Error unmarshalling response back from AWS. Response Body: {
"message": "Request forbidden by administrative rules",
"__type": "CloudSearchException"
}"
----> System.Xml.XmlException : Data at the root level is invalid. Line 1, position 1.
Code sample:
var _configClient = new AmazonCloudSearchClient(
WebConfigurationManager.AppSettings["CloudSearchAccessKey"],
WebConfigurationManager.AppSettings["CloudSearchSecretKey"],
new AmazonCloudSearchConfig
{
RegionEndpoint = RegionEndpoint.USWest2,
ServiceURL = WebConfigurationManager.AppSettings["CloudSearchUrl"]
});
await _configClient.DescribeIndexFieldsAsync(new DescribeIndexFieldsRequest())
CloudSearch is returning json, which you can see in your response body, and the SDK is trying to unmarshal that into xml. When you make a query directly, you can add &format=xml to get xml results. There should be an analogous option in the SDK.
I'm facing an issue with my (Register with Windows Live Account) feature in my portal
Simply the feature was suddenly stopped without any known reason and throws the following exception
Exception Message: Unexpected response Content-Type text/html
Source:
DotNetOpenAuth.Core
Stack Trace:
at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String unformattedMessage, Object[] args)
at DotNetOpenAuth.Messaging.ErrorUtilities.ThrowProtocol(String unformattedMessage, Object[] args)
at DotNetOpenAuth.OAuth2.ChannelElements.OAuth2ClientChannel.ReadFromResponseCore(IncomingWebResponse response)
at DotNetOpenAuth.Messaging.Channel.RequestCore(IDirectedProtocolMessage request)
at DotNetOpenAuth.Messaging.Channel.Request(IDirectedProtocolMessage requestMessage)
at DotNetOpenAuth.OAuth2.ClientBase.UpdateAuthorizationWithResponse(IAuthorizationState authorizationState, EndUserAuthorizationSuccessAuthCodeResponse authorizationSuccess)
at DotNetOpenAuth.OAuth2.WebServerClient.ProcessUserAuthorization(HttpRequestBase request)
at Ta3malWebParts.Membership.Registration.Registration.HandleWindowsLiveAuthorization()
The method causes this error is (WebServerClient.PrepareRequestUserAuthorization) this method should receive a JSON response from Windows Live, when i used Fiddler to check the response i found that the response content is JSON but the response header states that the response type is HTML, the above method contains an internal function validates if the returned response type is JSON or not, this validation throws the above exception.
Does any one have any idea how can we solve this issue.
Thanks in advance.
I'm doing a PayPal Express Checkout on my ASP.Net MVC site.
The site uses token authentication so I'm trying to put the token on the PayPal return URL as a query parameter.
I have a handler that intercepts all requests to my site and extracts the token from the URL or the request header.
Works fine getting it from the header but I get the following exception when its a query parameter. I get the token from my claims principal and don't do any encoding/decoding. I've tried this method but had no luck (same exception occurs).
System.ArgumentException was caught
HResult=-2147024809
Message=Jwt10204: 'System.IdentityModel.Tokens.JwtSecurityTokenHandler' cannot read this string: '{really long token}'.
The string needs to be in compact JSON format, which is of the form: '<Base64UrlEncodedHeader>.<Base64UrlEndcodedPayload>.<OPTIONAL, Base64UrlEncodedSignature>'.
Source=System.IdentityModel.Tokens.Jwt
StackTrace:
at System.IdentityModel.Tokens.JwtSecurityTokenHandler.ReadToken(String jwtEncodedString)
at {our namespace}.Providers.JwtTokenServiceProvider.GetToken(String value)
at {our namespace}.TokenAuthorisationController.Post(TokenRequest request)
Turns out the problem was that PayPal appending another string (that look like a PayPal Express Checkout token) on then end of the URL with a comma as a delimiter instead of the "&" symbol.
So I solved the issue by removing the comma character and the extra characters after the comma to extra my JWT token.
I am trying to pass a Uri of new Uri(".example.com")
Invalid URI: The format of the URI could not be determined.
or new Uri("http://.example.com")
Invalid URI: The hostname could not be parsed.
I need to be able to use the CookieContainer.SetCookies function which only has one overload taking a Uri.
According to this page, .NET 4.0 should support dot prefixed cookies now, but it seems the Uri class does not?
In this case, you need to pass a proper uri to the function, and the Uri parser is correctly rejecting the malformed string you are trying to use.
I would advise using the Cookie Constructor that takes 4 parameters - allowing you to set the domain to a dot-prefixed one.
Cookie(string name, string value, string path, string domain);