The Request Logger built into Service Stack looks to provide a great resource for easily. We’d love to use it, but out of the box anyone who can access the Swagger docs, can also get to the RequestLog URL and see all the requests anyone has made against the API which is a problem. How can we secure the Request Log UI?
The RequestLogs Service is only accessible in DebugMode or if you have the Admin Role, the RequestLogsFeature.RequiredRoles lets you change which Role it should be limited to, it defaults to Admin by default. Basically it wont be accessible in non-DebugMode Release builds.
How does it determine group/role permissions? I use a custom access provider on my services that uses an Auth2 redirect flow, but that’s not integrated here. When I just access the page how does it have any idea what roles I have?
ServiceStack only knows about Roles and Permissions when you’re using an Auth Repository, it can’t know about your custom Auth provider, you’ll need to either populate the Roles Collection on the UserSession or implement HasRole() on your Custom UserSession.
I can populate the Roles collection (I do so in my custom auth provider code) but I still am not clear on how to hook into my custom auth provider so that it causes the redirect when someone tries to access the Logger UI since that UI is not my code. e.g. with the OpenAPI UI, I was able to do this:
ApiDeclarationFilter = api => {
api.SecurityDefinitions.Add("oauth2", new OpenApiSecuritySchema { Type = "oauth2", AuthorizationUrl = "https://oauth.MYURL.net/connect/authorize", Flow = "implicit", Scopes = new Dictionary<string, string>() { { "myapi", "My API" } }, Description = "oAuth2 Implicit Grant" });
},
which hooked into the existing auth framework so the user could click on the exclamation point and click authorize and it would redirect them.
To be sure, I don’t even mind using some separate basic authentication with a hard coded username password combo for the trace log - it is internal only and the few of use who need access can share the user account. The issue is that currently we don’t have access at all and I can’t figure out how to get in (outside of deploying debug to production which gives everyone access).
Your Custom Auth Provider should be populating the UserSession which is what ServiceStack looks at to check for the role.
That’s the first sentence of my previous message…
Auth2 implicit flow works by redirecting a user to a login page on an Auth server and then redirecting them back to the page where the authorization is needed with a bearer token. When the service is accessed with the bearer token, the custom provider code extracts the rols information from the bearer token and sets the Roles and the UserSession. The last piece exists - all the rest is missing in the case of the logs. I explained how it works with OpenAPI.
Any response to this? Do I need to write my own logger? I believe if you read my message 3 posts up you will see I have explained the issue very well.
I’m trying to be clear here, in order for ServiceStack to be able to find User roles your Custom Auth Provider needs to populate and save a Custom User Session in the location where ServiceStack expects, i.e. in the Cache Client at the location it looks for so that the User Session is retrievable per request using the IRequest.GetSession() API:
The other way to tell ServiceStack what User Session to use for the Request is to inject the Users Session in IRequest.Items.
It doesn’t matter how your Custom Auth Provider is implemented if that API doesn’t return the User Session, ServiceStack can’t find it.
The only another way to access the logs without DebugMode or a valid User Session is to make requests as a Super User is to configure an AuthSecret which you can then add on the queryString to bypass authentication.
I completely understand what you are saying. My custom auth provider does that, as I have said.
The issue is the flow. In Auth2 flow, the custom auth provider is able to populate the Session based on the bearer token value. If that bearer token isn’t populated then the custom auth provider can’t populate the session. What’s missing here is how to cause the bearer token to get populated.
As I explained above, with OpenAuth, for example, the UI is able to force a redirect to the Auth login page, which redirects back to the OpenAuth pages with a set bearer token, so that when the API is called, the custom auth provider can set the session. I am asking what is the expected way to set that up with the request log UI? If someone browses directly to the request log URL, the bearer token wouldn’t be set.
If there isn’t any native way to hook into such a flow (like there is for OpenAPI), the auth secret seems like a fine solution. I’d just browse directly to the request log UI with that param in the URL?
Alternatively, I suppose I could just add an API which sits on top of the log service and secure it like I do everything else, correct?
Yes, the easiest solution is to configure an Auth Secret in which case you don’t have to integrate with ServiceStack’s UserSession and can view the logs with:
/requestlogs?authsecret=secretz