ServiceStack authentication design questions

[Gerke Geurts]

Hello,

 

I am looking at integration Windows authentication into ServiceStack and seeing how it could fit in the existing authentication design. Based on my investigation so far I am wondering why ServiceStack is not using an IPrincipal based API, as IPrinicipal is the common way to get/set authentication and authorisation info in both web and desktop apps.

 

Kind Regards,

Gerke.

 

 

[Demis Bellot]

ServiceStack is completely disconnected/decoupled from all of ASP.NET's existing in-built providers including the existing .NET Authentication model.

ServiceStack's Auth Provider model provided supports all the Cache Clients and back-end Auth Repositories, in self-host + on Mono, with OAuth providers / Basic / Digest Auth etc. That provides more metadata + merges authentication from different auth sources, etc. We're able to provide a cleaner and more flexible and re-usable code-base by not mapping to existing ASP.NET providers.

Although in future we do intend to provide integration with ASP.NET Authentication in our future stable + commercially supported versions of ServiceStack.

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[clayton collie]

I had the same question. I ended up creating an AuthSession wrapper as a workaround. BTW IPrincipal predates and is orthogonal to ASP.NET (its in the System.Security.Principal namespace after all), and its useful for integration with other libraries (eg.by way of Thread.CurrentPrincipal)

[Gerke Geurts]

The current authentication design assumes that authentication is always linked with a session. The implementation of basic and digest authentication has been shoe-horned into this design. That is an indication that the current authentication design is not using the right concepts/abstractions yet to match the various authentication models that rae being used on the web.

 

My suggestion would be to add a user property to IHttpRequest or IHttpRequestContext of type IPrincipal and to implement the OAuth authorisation logic in an OAuthPrincipal. When using the integrated authentication features of the HTTP listener implementation, the User property could be defaulted to the user as already authenticated by the HTTP stack.

 

Regards,

Gerke.

[Jon Canning]

I found the Auth Provider model didn't really fit with my OAuth implementation, so I do my authentication in a custom request filter that ends with:

            var genericIdentity = new GenericIdentity(accessTokenInfo.UserName);

            httpContext.User = new GenericPrincipal(genericIdentity, null);

[Demis Bellot]

Right, if for whatever reason you don't like the shoe-horning happenings and the incorrect abstractions/concepts used in the AuthProvider that aren't able to match the various authentication modes that are used on the web (even though they currently do just that)... well then you can always use your own that are a perfect fit.

The Auth Providers are completely optional and you're free to plug-in your own using built-in Request Filters.

[Gerke Geurts]

Let me make clear I like ServiceStack and the simplicity, power and portability it brings, otherwise I wouldn't spend time trying to understand its inner workings in order to make the extensions we need as simple as possible. There might have been an important reason why the existing .NET authorisation and authentication model was not used in ServiceStack. That was the background for my question. I am also pretty certain that other people may come up with similar questions as use of ServiceStack becomes more pervasive.

 

I appreciate the great effort that has gone into the framework so far and what you and other collaborators have achieved up until now. Having said that, any framework has room for improvement, and ServiceStack is no exception. My comments on the design of the authentication login in ServiceStack were not meant to cause offense, but to get clarity about the forces and history behind the design decisions.

 

Kins Regards,

Gerke.

[Demis Bellot]

Here's what it takes to register 8 different providers inside a single Registration. It might exist, but I haven't seen any other framework that makes it that easy to support different Auth Providers. 

So I'm not buying that it's using the wrong abstractions incapable of supporting different auth models used on the web.

At the same time a single implementation can't support all things for all people, it's been designed so it does its best to support multiple caching / auth repository back-ends and Web Auth strategies whilst retaining a simple & declarative configuration. 

In order to provide a flexible and testable solution that can be cleanly re-used in any host, we've stayed clear of trying to support *any* of the existing ASP.NET providers. It's attached to the user session since that's where all user state should be held so service impls can retrieve all user state with a single cache hit. I don't agree Authentication should be treated differently and maintained in a different area. Most other platforms implements authentication in user-space which is where I think it should be.

Although as it's opinionated, its intend to be completely optional, that's why it's baked into the higher user-level ServiceStack.ServiceInterfacs.dll rather than the core ServiceStack.dll. Either way it's easy to inject your own Authentication strategies using the same techniques that it uses (e.g. Request Filters).

But if you think you can enhance the existing Auth Providers without introducing complexity or forcing more burden on end-users (e.g. configuration), then sure we welcome pull-requests sharing the same goal.

[Stan B]

Is there a reason why IRequest cannot have a property called User? I have custom authentication filter in which I need to store certain properties of the authenticated user. I need these properties to be available for the duration of the request. I don't want session. I don't understand the benefits of having one.