stormpath / stormpath-dotnet-owin-middleware

OWIN middleware for Stormpath and .NET

Stormpath is Joining Okta

We are incredibly excited to announce that Stormpath is joining forces with Okta. Please visit the Migration FAQs for a detailed look at what this means for Stormpath users.

We're available to answer all questions at [email protected].

Migration guide

The latest version (4.0.0 and later) of this library supports migrating applications from the Stormpath API to the Okta API. For more information, see the migration guide.

For a full list of breaking changes, see the changelog.

ASP.NET or ASP.NET Core? Easy!

If you are building an application with ASP.NET 4.5.1+ or ASP.NET Core, head over and grab the packages from those respective links.

stormpath-dotnet-owin-middleware's Issues

Improve error messages

A lot of errors (especially ones at startup) are piped verbatim from the REST API, which leads to some confusing DX. A better experience would be to augment error conditions with additional info or links to the documentation.

• API key ID required - link to info about supplying Stormpath credentials
• Authentication required - could be bad credentials, wrong environment (api, enterprise, eu), bad digest

More to come...

Headers aren't always sent

Tests that check for cache-control headers are failing sometimes because the OWIN server is modifying headers before the response is sent. Try using OnSendingHeaders to hook into this.

Exception is thrown on startup

After upgrading to 0.8.0, some projects fail to start with an exception thrown from BuildSafeServerUrl().

Add optional logging

SAML callback handler

The Stormpath assertion handler needs to be able to handle incoming callbacks from SAML IdPs.

Check that Stormpath middleware is not already added

A simple sanity check could be implemented to look for the existence of OwinKeys.StormpathClient in the OWIN dictionary. An error should be thrown if the Stormpath middleware is added to the pipeline twice, because we can't guarantee the behavior (it would be odd...)

Stormpath Framework 1.0 compliance

Investigate authorization handler behavior when access token expires

From stormpath/stormpath-aspnetcore#28

After some period of time user still logged in but cannot access resources with policy. Logout and in again solves problem but is is not the way it should be

but looks like it is related to refresh token time. I changed it to longer period and it is fails less frequent.

CSRF support

Cannot sanitize type 'IAccount' after login

This was inadvertently broken in cecdbf5. Need to revert and push out a fix.

PreLoginHandler should allow targeting nameKey

Right now the PreLoginHandler can be used to target an accountStore, but not an organizationNameKey.

Logout refreshes an expired token/cookie, doesn't log user out.

In our .NET implementation, we are seeing that logout is actually refreshing a user's access token (and not logging out), if the user clicks logout any time after the token has expired. This requires the user to hit logout again in order to actually log out. If the token has not expired, logout works as expected.

Tokens aren't revoked on logout for Bearer authentication

If a client passes an access token up to the server via an Authorization header and hits the /logout route, the token is not revoked on the Stormpath side.

If the token is passed via cookies, it is revoked properly.

ID Site support

Secure redirection/deeplink mechanism

ID Site, SAML, social, and protected routes all need a way to support "deep linking" so that you can be redirected back to your intended destination after authentication. Currently, the route protector just appends ?next=/relative/uri but a unified (and more secure) system is needed.

Nancy support

ScopedLazyUserAccessor isn't returning correct account

Reported in stormpath/stormpath-aspnetcore-example#2

Support .NET Core RC2

Social login support

Described in https://github.com/stormpath/stormpath-framework-spec/blob/master/social.md

Support for swagger

I would love to see an implementation that plays nice with swagger and Swashbuckle. Right there is not an easy way to setup cookie auth and the runtime generated stormpath endpoints do not show up in the swagger ui.

Cookies are not saved on MS Edge

Chrome persists the access_token and refresh_token cookies correctly. It seems like Edge doesn't - this needs some digging.

Allow developer to specify cache provider

The cache configuration can be customized using the existing StormpathConfiguration object, but the specific cache provider to use (InMemory, Redis, etc.) cannot.

Basic authentication support

Described in https://github.com/stormpath/stormpath-framework-spec/blob/master/authenticators.md#types-of-authentication

Pre- and post-action handlers

Move the ClaimsIdentity code to the OWIN layer and make it customizable

The transformation from JWT -> IAccount -> ClaimsIdentity is currently hardcoded, but should be customizable.

This should include unit tests for the transformation mechanism and typical token scenarios.

Multi-tenancy support

This will mirror the features coming in express-stormpath.

Accept header parsing is sometimes incorrect

There seem to be some instances where the middleware returns JSON instead of HTML as expected. One case that does not work correctly:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Hardcoding the stormpath.web.produces setting to only contain text/html should work as a temporary fix: https://docs.stormpath.com/dotnet/aspnetcore/latest/configuration.html#disabling-content-types

Remove any fake emails used in tests

Per stormpath/stormpath-sdk-dotnet#225

AutoLogin support

Described in https://github.com/stormpath/stormpath-framework-spec/blob/master/registration.md#-autologin

Angular SDK doesn't display social buttons

The .NET backend is not sending the proper data to the frontend, so the Angular client is unable to render the social buttons correctly. See stormpath/stormpath-sdk-angularjs#160

/me route ignores text/html requests

It's not possible to hit the /me route with a browser, because it specifically looks for Accept: application/json. It should be a little more flexible, so people can test the route in a browser.

Improve startup time

There are a number of network calls required when StormpathMiddleware is starting up. These should be optimized/parallelized if possible.

Rename passwordAgain to confirmPassword

In anticipation of the framework-spec being modified in the future to define the second password field on /change to be called confirmPassword, it should be changed from the current name (passwordAgain).

Claims in thread principal can be out of date

When using the SDK to perform a password grant, using the access token in subsequent calls can provide out of date principal information. This may or may not be an issue using the provided /token route, but our organization does not use it, we do everything through the C# SDK.

To reproduce:

1. Acquire an access token from Stormpath using the SDK.
2. Pass the token to a route with the [Authorize] attribute.
3. Note that the claims on the thread principal are correct, such as the name and email address.
4. Change the username, email address, or both on the user in Stormpath either through the SDK or right through the administrator UI.
5. Repeat steps 1 and 2 above.
6. Note that the claims on the principal are now out of date, the username and email address do not accurately reflect the change made. Even making a call to get the details using the user's HREF are not accurate.

The expectation being that if a new token is acquired, that token should contain completely up to date information.

Authorization helpers

This will be migrated from stormpath/stormpath-aspnet#6

Sync up with TCK

Honor /me expansion configuration

The /me endpoint can be configured to automatically "expand" collections like Groups, to retrieve more information about the user. Currently, the middleware ignores this setting.

Render buttons for SAML directories on /login

After #36 is done, buttons should be rendered automatically.

Application fails to authenticate in Stormpath when API Key and Secret are NOT hardcoded.

This problem exists when building a .NET Core RTM WebAPI.

Following the instructions on the documentation site, I attempted both putting the API key and secret in an environment variable and in a stormpath.json and .yaml file at the root directory (not at the same time). In all cases, my application was unable to authenticate against the Stormpath API. Although, I should note any additional configurations in the .json/.yaml file were picked up and applied, so it's not a case of the not being found.
If I instead put the key and secret in the ConfigureServices method in Startup.cs during the services.AddStormpath() call, everything works as intended.

I originally talked to Michele Degges about this over the support ticket system and she confirmed my files were correctly formatted. We could only conclude that something must be up with my setup.

Create callback URLs for social integrations dynamically

If I don't specify a base url for the application, I get this error:

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Stormpath.Owin.InitializationException: The stormpath.web.serverUri property must be set when using Google login integration.

I think it would be better to dynamically construct a redirect url based on the hostname and scheme that the server is using, rather than another config property.

Support POSTs with a mismatched Accept/Content-Type

Right now, a request like this will fail:

POST /login
Accept: application/json
Content-Type application/x-www-form-urlencoded

The route handler is assuming that Content-Type will always follow Accept, but that's not always the case (JS clients do strange things sometimes). Content-Type should go through its own validation and be disconnected from Accept.

Logging improvements

• Include more detail when Stormpath errors are logged (developer message, request ID, etc)
• Switch over to Microsoft logging abstractions library (might be pushed to a future release)

Expand accounts by default

For faster authorization, it'd be nice to expand accounts by default (probably customData only).

ASP.NET 4.x support

In addition to ASP.NET Core, we need to support "legacy" ASP.NET 4.x.

Basic authentication support

Full API documentation

Visual Studio Code launches wrong URL after adding Stormpath Middleware

After adding the Stormpath Owin Middleware, F5 to launch the app in VS Code launches https://localhost instead of http://localhost:5000

Just a little annoying to always have to change it by hand. but it is definitely still running on localhost:5000.

Client credentials grant support

Logout cookie headers are malformed

From stormpath/stormpath-aspnetcore#23

Set-Cookie:access_token=path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT; HttpOnly
Set-Cookie:refresh_token=path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT; HttpOnly

It should have a semicolon+space after access_token=

Access the IClient during PreLoginHandler

It's currently not possible to access the Stormpath Client within the context of a PreLoginHandler. PostLoginHandler is okay, because the Client is accessible from the IAccount object.