I would really like to see out of the box support for IWA - Integrated Windows Authentication with Active Directory. Many in-house .Net developers for both large and small organizations write web applications that are Intranet facing, and require the use of Integrated Windows Authentication with IIS. In these environments, corporate security policy often dictates that Active Directory group membership should drive what resources a user can and cannot access.
So, Kerberos authentication often plays a big part in shipping the logged in user’s credentials via tickets from the application server to back end databases. Built-in support for a ServiceStack web service to be Active Directory aware would be awesome and would simplify implementing this security! We currently use Filter Attributes to get this desired behavior for our ServiceStack web services but would love to see this important part of security built in to the stack to simplify integration.
Thanks,
Jeff Ronay – Cleveland, Ohio

I'd like to see a deeper integration between ServiceStack and SignalR. Here are a few ideas that I've so far ran into...

1. A Hub Authorization Attribute which implements IAuthorizeHubConnection and/or IAuthorizeHubMethodInvocation.

2. Some sort of JsonServiceClient integration with HubConnections. Maybe automatically associating Cookies with a new HubConnection. Plus exception handling wrappers (i.e. Like an Unauthorized exception is thrown within a SignalR exception).

3. Centralized documentation outlining what needs to be changed in the web.config for SignalR to co-exist with ServiceStack. Also why the UseBufferedStream property should be enabled for SignalR.

4. This might require a separate feature request but an updated example app showing SignalR 2.0 integrated with ServiceStack 4.x. Only Examples I've seen have been with SignalR 1.x

Add the most efficient remote endpoint for consuming ServiceStack services.

Ideas: use https://github.com/nanomsg/nanomsg (by author and successor to ZeroMQ in C).

Advantages: Abstracts IPC/TPC/InMemory for picking the most efficient transport. Can easily interoperate with other NanoMsg clients on other platforms. C is nice to embed than C++.
Disadvantages: Still in Alpha, unclear when it will be stable/safe to use. Still native, requires effort to use 32/64 bit architectures and cross-platform on Mono.

Alternative: Build endpoint on raw TCP sockets in C# using something like Redis wire protocol for efficient transfer of message payloads. Could imitate operation on redis-server for interoperability with other redis clients or mask itself as a LUA operation for greater flexibility.

RAML (see raml.org) is pretty sweet as a design tool... like Swagger 2.0, you can design your full API and corresponding documentation in the designer tools.

It would be nice to have ServiceStack support reading RAML generated specs and automagically create the corresponding ServiceStack API with stubbed in methods.

One of the nice things about RAML is the ability to generate a mock JSON responses and/or status codes from a specified endpoint as directed by the RAML designer tools. This allows it easy for other peer developers (and regression tools) to consume your service although it might still be under development or is incomplete.