In ITfoxtec SAML 2.0 implementation, Saml2PostBinding object has SetRelayStateQuery() and GetRelayStateQuery() methods to set and get data from dictionary.
Sometimes, GetRelayStateQuery() returns Empty dictionary even though I have set values using SetRelayStateQuery(). I am not able to reproduce this while testing but it is happening for many clients on production. In which scenarios may this happen?
The SetRelayStateQuery() should be used in the RP (relying party) and then the GetRelayStateQuery() in the IdP (identity provider). The methods should not be used in the samme application.
You can trace the error by looking at the SAML send between the parties.
Related
I have been reading a book about SAML 2.0 lately. There was a point in regards to the "typical use and usefulness of SAML metadata" stating the following:
The SP wants to authenticate a user. It looks at the metadata and finds the URL at the IdP where users should be sent. It uses its private key to sign the authentication request and sends it to the URL at the IdP.
The line I am interested the most (and the one I do not well understand yet...) is:
It uses its private key to sign the authentication request and sends it to the URL at the IdP.
My question is - where exactly in any of the existing standard/RFC/alike document may I find info on these exact points mentioned in the SAML book - signing, calling?
For example, it is not clear for me if that's the call signed by a standard HTTPS process or is it SAML-specific-signing + HTTPS, what type of algorithm is in use at signing, what kind of call should happen (GET, POST, other), what kind of parameters (if that's important at all) should be sent with the call... and alike questions related to signing and sending arise. I expect a document of some kind to get into more details and explain signing and calling procedures. Not much success on finding precise pages in right documents yet. Seems like RFC 2818 may be a good direction, or one of many SAML 2.0 specifications, or else.
Pointing to (the part of) the right document containing the info on the signing and the calling would be appreciated. Elaborating a bit on the given quote I do not understand would also benefit a lot.
You have a lot of questions - Not surprising as SAML is a large topic. And there are a lot of documents. Take a look at the following link as it would walk someone through integrating perl's Net::SAML2 into a web application and walks through the steps.
https://github.com/perl-net-saml2/perl-Net-SAML2/blob/master/TUTORIAL.md
However it does gloss over some things. Early on it says:
The IdP object contains the Identity Providers settings that were parse from the metadata and are then used for the rest of the calls.
In that you see a
'sso_urls' => {
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' => 'https://accounts.google.com/o/saml2/idp?idpid=CXXXXXXXX',
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' => 'https://accounts.google.com/o/saml2/idp?idpid=CXXXXXXXX'
},
If you ignore the 40+ page doc on metadata https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf These are the two methods the IdP used for the sign on and specified a HTTP-Redirect and a POST method. IN this case the URL's match but they do not need to.
The creation of the HTTP-Redirect for the AuthnRequest alone is a minor feat. https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf. Page 15 3.4 HTTP Redirect Binding describes the method. It is essentially taking the XML AuthnRequest and using the DEFLATE compression method (see
[RFC1951]) The result is Base64 encoded and assigned to SAMLResponse and has the RelayState (if any) and SigAlg appended as GET request parameters. The result is Signed using a accepted algorithim like rsa-sha256 and the base 64 signature is added to the query parameter that are normally URL encoded to be requested via the browser. See https://github.com/perl-net-saml2/perl-Net-SAML2/blob/064f718178c3fa6edfe0b262fe4b5e4c8705411b/lib/Net/SAML2/Binding/Redirect.pm#L117
So, learning it is walking through each part of the process. There are multiple documents that address certain parts. It relies heavily on other existing standards and RFCs. For instance the POST request and much of the communication uses xml-dsig unlike the HTTP-Request (space limitation in URLs). That is a beast in itself.
I support Net::SAML2 and can answer specific questions. Despite its size SAML is a fairly simple (yet extraordinarily complex) protocol. I quite like it
I think it is my book you are referring to =) SAML 2.0: Designing secure identity federation
SAML is not straight forward and simple so you are not alone in having difficulty in grasping it. You have a lot of questions but I will try and answer them as best I can.
How SAML messages are sent is called bindings. For example POST or Redirect. These are defined in the bindings spec and discussed in chapter 6 of the book.
SAML traffic should always use HTTPS, but in addition the XML should be singing to protect the message from tampering in the browser as HTTPS does not protect against this. The difference between these are discussed under Transport and message protection in chapter 12 of the book.
What messages are sent how they are sent and and how they need to be protected in SSO is defined in the Web Browser SSO Profile in the profiles spec and discussed in chapter 8 of the book.
How signatures are processed and formats are defined in chapter 5.4 of the SAML core spec
I hope this helps to guide you right.
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.
We currently have ADFS 2.0 with hotfix 2 rollup installed and working properly as an identity provider for several external relying parties using SAML authentication. This week we attempted to add a new relying party, however, when a client presents the authentication request from the new party, ADFS simply returns an error page with a reference number and does not prompt the client for credentials.
I checked the server ADFS 2.0 event log for the reference number, but it is not present (searching the correlation id column). I enabled the ADFS trace log, re-executed the authentication attempt and this message was presented:
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
As the message indicates that the request is not well formed, I went ahead and ran the request through xmlsectool and validated it against the SAML protocol XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) and it came back clean:
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
So, I'm thinking that ADFS isn't playing full compliance with the SAML specification. To verify, I manually examined the submitted AuthnRequest, and discovered that our vendor is making use of the 'Extensions' element to embed their custom properties (which is valid, according to the SAML specification) (note: "ns33" below correctly namspaces "urn:oasis:names:tc:SAML:2.0:protocol" elsewhere in the request)
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
If I remove the previous element from the AuthnRequest and resubmit it to ADFS, everything goes swimmingly. And, in fact, I can leave the 'Extensions' container and simply edit out the vendor namespaced element, and ADFS succeeds.
Now, I guess I have 3 questions:
Why was the reference number not logged to the ADFS log? That really would have helped my early debugging efforts
Is it a known issue that ADFS's SAML handler cannot handle custom elements defined within the Extensions element, and if so, is there a way to add support (or at least not crash while handling it)? My vendor has offered to change the SAML AuthnRequest generated to omit that tag, but said that it 'may take some time'-- and we all know what that means...
Does anyone think that installing ADFS hotfix rollup 3 will address this situation? I didn't see anything in the doc to indicate the affirmative.
Thanks for your feedback.
When facing a MSIS7015 ADFS error, the best place to start would be enabling ADFS Tracing. Login to the ADFS server as admin and run the following command. If you have a very busy ADFS server, might be wise to do it when the server is not as busy.
C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc
In Event Viewer select “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Go to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging.
Process your ADFS login / logout steps and when finished, go to the event viewer mmc find the sub tree AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
Look for EventID 49 - incoming AuthRequest - and verify values are not being sent with CAPs value. For example, in my case, it was I was receiving the following values: IsPassive='False', ForceAuthn='False'
In my case, to address the issue, all I needed to do was create incoming claim transformer rule - for the distinct endpoints.
Once the CAPs were transformed to lower case true and false, authentication started working.
Http Form adapter serves as an authentication service in my application. I have not implemented any application on the Identity Provider to get user inputs.
Therefore, on successful authentication, SP verifies the user's signature and redirects to the application. At my target Resource, I receive an open token. Is it still possible to utilize the open Token Jar to read the user attributes from OTK?
**Note: ** In Service Provider, I use open token Adapter.
Also, please let me know if there is any other possible way of getting the user attributes other than using the open token adapter/http form adapter.
Thanks.
There are numerous SP Adapters you can choose to use for your last mile integration with your application. The OpenToken Adapter is just one of them. If your application is in Java and you are using the SP OpenToken Adapter, then you would most likely use the Java OpenToken Agent implementation within your application to read the OTK (documented in the Java Integration Kit). If you look at the Add Ons list, there are actually 3 flavors of OTK Agents (.NET, Java and PHP from PingID. Ruby on Rails and Perl are available via respective Open Source repositories).
However, you are not limited to OpenToken Adapters. The Agentless Integration Kit is also very popular for SP/last-mile integration with PingFederate.
Unfortunately, the question is just too open ended for the Stackoverflow format. I would suggest talking to your Ping Identity Solution Architect who can help steer you in the right direction and ask the necessary follow-up questions on your use case.
If understand the question correctly, you desire attributes to be fulfilled that the web application can read and utilize. This starts with the SP Connection configuration. I am going to assume you are using Active Directory and already configured that data source along with the Password Credential Validator (PCV) for the HTML Form IdP Adapter. In the SP Connection you will need to extend the attribute contract to define the values to put into the SAML assertion and then use the Active Directory data source to fulfill the attributes. When the SAML assertion is received by the PingFederate SP role server, the SP Adapter maps the attribute values from the SAML assertion into the OpenToken. When your application receives the OpenToken, it can read the values.
Right now I've got Spring Security protecting an application using basic authentication. The user details are coming from a JDBC source. If the database goes down, the internals of the user loading mechanism will throw a DataAccessException. The default authentication provider class, DaoAuthenticationProvider, catches the exception and maps it back to an AuthenticationServiceException. The end result of such a mapping is that the browser/client receives HTTP code 401.
What I want to do is to handle database unavailability in a different way. At the very least, I want this to be handled by responding with HTTP 503 but I would prefer if it redirected to an error page. How can I achieve this?
EDIT: Ritesh's solution was partially correct. The missing steps apart from implementing your own Basic entry point is to also use v3.0.3 of the security schema so that the <http-basic/> element has the entry-point-ref attribute. If you don't use this special attribute, the default Basic filter will always use its own Basic entry point implementation.
The BasicAuthenticationEntryPoint sends 401 for AuthenticationException. You can create your own custom entry point to handle AuthenticationServiceException and send out 503.
Other option is not to do anything in entry point and use SimpleMappingExceptionResolver and/or implement your own HandlerExceptionResolver.