For sometime, we have been using an [Authorization] attribute of our own (RequestFilterAttribute) for verifying the calling user has a Bearer token in the headers of the request.
If there is a Bearer token, we use DontNetOpenAuth to examine/verify and extract the user details from the token, and then we set the current IPrinicpal using code like this:
var httpRequest = (HttpRequestBase)request.OriginalRequest;
httpRequest.RequestContext.HttpContext.User =
new OAuthPrincipal(token.User, id, access_token, roles);
Later, in other code we can examine the current user (i.e. username, ID, Roles etc) for doing things like role checking etc, or user based operations.
On reflection, we are in effect passing information about the calling user in the actual IPrincipal of the HttpContext.
Is there a more ServiceStack way of passing that information around instead of storing it in the HttpContext?
(i.e. IRequest.Items)
ServiceStack Authentication is completely decoupled and independent to built-in ASP.NET Auth, the recommended way is to store user data in a Custom User Session which also lets you override how Roles and Permissions are validated by HasRole() and HasPermission(). This would then lets you use the built-in [RequiredRole] and [RequiredAnyRole] attributes or you could verify a user has a role explicitly in your Service with session.HasRole().
Other than that, there’s only IRequest.Items Dictionary used to pass data about the request throughout different handlers and filters throughout the Request Pipeline.
I am tempted to move us over to ServiceStack Authentication, and use what you suggest.
I am hoping its just a drop-in replacement.
Our current impl was heavily influenced by @DylanBeaties work a while back, and we have our own OAuth resource server that does the actual authentication and serves its own oAuth access_token.
So some pieces I don’t yet understand, that I need to get my head around first (if you will permit me?):
In our services, we are verifying the HTTPAuthorization header of each request as a Bearer token, and using DNOA to verify the signatures of the token and decrypt the content etc. What SS plugin will do the same, or is this class up to us to code?
I will need to stuff into the Custom Session custom data about the user that is also coming from within Bearer token, Is that possible?
Can I access the custom Session from any of my service operations? I will need to fetch the ID, username and roles of the current user which is stuffed in the Session (coming from Bearer token)
There’s nothing built-in ServiceStack that already does this, the OAuth Providers work similar to any other Auth Provider where the end result is a populated User Session stored in the registered ICacheClient