sustainsys / saml2 Goto Github PK

Make it possible to set the nuget version explicitly when building the package.

I started writing the Saml2AuthenticationModule as a HttpModule because WsFederationAuthenticationModule is a module. But while the WsFederationAuthModule works on any request that has the right form fields passed in, SAML2 works only on specific URLs. Looking closer at how IIS is designed it might make more sense to install the SAML2 handling as an http handler instead of as a http module.

Add tests and check that responses with a status indicating failure (such as status:Requester) and a missing signature on the entire message are allowed. If there is a signature it must be valid.

The new ASP.NET Identity system contains functionality to handle external logins. Make a login provider working with ASP.NET Identity.

For now, it will be sufficient to create an Owin middleware that works with the ASP.NET Identity system when hosted on IIS. #82 takes this further and enables support for hosting outside of IIS.

Expose metadata from the SP.

Readme in the nuget package that is autodisplayedk, including links to the documentation in the github repo.

Saml2Response.Validate expects the Signature element as a child of the Response element(xmlDocument.DocumentElement). This signature element does not have to be present. It's able, that every Assertion element has a Signature element, containing the signature for the specific Assertion only.
ADFS2 just uses the signed assertions and omits the Signature element in Response.
Please adapt the signature validation in a way, that both possibilities are handled correctly.

Add support for single logout according to the section 3.7 in the SAML2 specification.

Create a test to verify that a message signed by cetificate(s) not in the list of trusted certificates fails,

Create automated integration tests (Coded UI Tests? Selenium?) that are run against the StubIdp, for both SampleMvcApplication (testing Kentor.AuthServices.Mvc) and SampleApplication (testing the Saml2AuthenticationModule).

XML signatures should only be accepted if they contain an enveloped signature. They may also contain EC14N canonicalization transform. If any other transforms are present, the signature should be rejected. See SAML2 Core 5.4.4.

Currently exceptions are caught by the commands and converted to proper CommandResults with errors. When moving to MVC controllers we want the exceptions to propagate, so the exception catching should be moved to Saml2AuthenticationModule instead.

#27 Preserve whitespace when reading SAML response from Idp. was fixed without any unit tests being added.

Try to add a test if possible that fails when the PreserveWhitespace flag is false.

• Be able to produce a AuthnRequest for an Idp over Redirect binding.
• Be able to receive, validate and correctly handle a response over Post binding.

Create a separate Nuget package for the MVC component.

A stub idp that can be used when testing full integration tests.

A response could possibly have a correct signature on the entire message, while one or more assertions are separately signed with a signature that fails validation.

This situation should never be possible in the first place, but if it happens, it indicates a buggy IDP and I think that the entire response should be rejected in that case.

Make a custom deploy.cmd for Kudu that runs the unit tests on deploy (and block if the tests fail).

Add support for multiple IdPs.

A suggestion is to use ~/SamlAuthenticationModule/SignIn/IdpName and let the SignIn command check the config for an idp with name="IdpName". If no name is specified, the first idp should be used. This also requires Saml2AuthenticationModule.OnBeginRequest to break out the first part of the URL and pass any remaining parts to the command.Run() method.

Refactor Saml2AssertionExtensions.ToXElement so that the subject and conditions are not handled in the same method. The handling of those should be moved to separate extension methods in separate classes. The tests in Saml2AssertionExtensionTests should be simplified to just check that the subject and assertion nodes are present. The contents themselves should be tested in the new tests for the new methods.

Create a NuGet package and publish.

Saml2Response uses XmlDocument to be able to use the XmlSignature class. Now, with the support of signed assertions everything is bounced over string formats anyway, so change Saml2Response to use XDocument instead.

XML Signatures without a ds:Reference according to SAML2 Core 5.4.2. should be rejected.

To use the stub idp now you need to figure out that the certificate is located at https://github.com/KentorIT/authservices/blob/master/Kentor.AuthServices.StubIdp/App_Data/Kentor.AuthServices.StubIdp.pfx
The certificate is required to use the stub IDP as any reasonable SP implementation would verify the certificate of any signed messages.

Just setting 404 status for invalid URLs without any error message isn't very user friendly. Find out a better mechanism. Preferably one that integrates seamlessly with custom error pages used in the hosting application.

In several places, strings are used for Ids etc, but there are built in classes that validates additional rules that should be used instead. Go through the entire library and fix.

Known issues:

• Convert Saml2RequestBase.Id from string to Saml2Id

Documentation on GitHub.

• Improved Readme.
• Configuration reference and examples.
• Contribution info.
• Example application info.

CheckSignature method on SignedXml is not able to work with RSA-SHA256 method. Please implement a solution as described at "http://geekswithblogs.net/mkoerner/archive/2013/07/12/saml2-federationmetadata-validation.aspx"

There are lots of ways validation can fail.
To help users of the authservices library to diagnose validation errors we should add trace logging before returning false in validation.
Make sure we don't leak security sensitive details.

There's a lot of places where there is code like someDate.ToString("s") + "Z". Extract that to an extension method on DateTime instead.

Check if it is possible to make Kentor.AuthServices.Mvc depend on AspNet.Mvc >= 1.0 instead of >= 5.0 as it is now. The mvc library only inherits from the Controller class, so it has no dependencies on 5.0 functionality.

There are some parts of the code outside Saml2AuthenticationModule that are not covered by tests. That should be fixed.

Find a better design. One idea is to write a new ValidateToken() that takes a flag to signal that a signature is already validated at the message level.

Create configurable options for validation of audience:

• Always - require audience restrictions.
• IfPresent - validate if there is a restriction in the answer.
• Ignore - never validate.

Might be a good idea to move the setting to the identityProvider level to make it configurable on a per idp level.

When packaging a nuget package, the version numbers should be automatically increased and a tag applied.

Improved documentation in the nuget package for the nuget gallery page.

For MVC applications it would make more sense to have the SP as an MVC controller. It would allow error handling to be seamlessly integrated in the error handling of the application.

This probably requires some changes to how exceptions are handled in the ICommandimplementations and in CommandResult.

The MVC integration should go into an own lib/package so that the core lib isn't dependant on MVC.

Make Xdt transforms that adds the necessary entries to the web.config when installing the nuget packages.

Check how Saml2Response.Validate works when there is a status message that is not "Success". Validate should not return true if the entire message is marked as an error. Figure out if it is best to return false or to throw an error (the latter would indicate that the caller should first check the result code before calling Validate).

Retreive and use Idp metadata instead of configuring everything. Including possibility to use a federation meta data source that contains info about several idps.

Add license and copyright header to all source files according to best practice for LGPL.

Automated integration tests for the sample applications when #21 is complete.

The signature validation in Saml2Response is getting quite big (and the corresponding tests are a bit messy as the handle complete Saml2Responses). Refactor the actual checking of the signature to an own helper class (extension method?) and move/simplify tests accordingly.

There is a specialized type for Saml2 Ids - make Saml2Response.Id use that one instead of being a string.

The documentation on how to getting started with the MVC controller obviously is not good enough: http://stackoverflow.com/questions/22004628/how-should-i-implement-samlp-2-0-in-an-asp-net-mvc-4-service-provider/22062966?noredirect=1#comment33495529_22062966

Add possibility to automatically derive the ACS and discovery service response URLs from the current request.

Doing this will require each of the three APIs (http module, MVC Controller & Owin Middleware) to extract the base url of the application for each request. This probably interacts with #101.

Saml2Response.GetClaims() should check that the status of the entire Saml2Response message is Success before returning any claims.

Validate InResponse to in the saml responses. There are stub tests Saml2Response_Validate_FalseOnIncorrectInResponseTo, Saml2Response_Validate_FalseOnInvalidInResponseTo() and Saml2Response_Validate_FalseOnSecondInResponseTo() that should be implemented and should cover the functionality.

An idea for implementation:

• Keep an in memory list of issued IDs.
• Only accept incoming responses that are present in the list.
• On accept: remove the id from the list.

This will work and will fails safe: if the server is restarted and the id is lost, the incoming response will be denied. A more complete implementation would retain used ids for some time and mark them as used. Ids that have timed out or been used should be removed after some time.

It might be possible to reuse the id cache used by DetectReplayedToken.

Create a configuration option to allow audience restrictions to be bypassed.

This requires a more flexible configuration handling to be able to inject different configs for different tests.