Need a way perform integration tests that use entity permissions
Closed this issue · 6 comments
I am able to stand the rest lightblue instance, however the metadata I am using requires a certain permission. It would be useful if there was a way to test permissions in test cases without the need for an actual cert.
As a client, what is the use case for requesting something from a secured lightblue environment when you don't have a cert? The cert authentication happens at the container, not in lightblue. It's required for all requests. Meaning, cert auth makes no decisions based on the content of the request. I don't see having a hole through this as being a good thing, architecturally.
I am a little fuzzy on the specific mechanics here, which is why I tried to leave the description somewhat vague so not limit the solution. That said, blaming the cert might have been a misconception on my part and confusing to everyone else.
My use case pertains to lightblue-platform/lightblue-migrator#142.
The migrator defines two entities (migrationJob & migrationConfiguration) that both require specific schema level access (aka Role) in order to perform CRUD operations on them.
AbstractCRUDControllerWithRest is being used to drive the migrator integration tests and itself does not use cert authentication. Again, that might be a red-herring anyway.
A ClientIdentification implementation is consulted to determine if the user is in the role or not, but as far as I can tell, the only way to associate users to roles is via HttpServletRequest.isUserInRole(role).
What I want to be able to do is control (in a test only environment) if a user is in fact in a role or not so that I can setup testing scenarios. So again, take my migrator use case, if I want to setup a test by populating migrationConfiguration data I am currently being denied because my user has no way to be associated to the group the metadata requires.
I believe what you're asking for is done by overriding the security context. Take a look at TestSecurityContext and see if that's what you need.
Looks like that is on the right track, but a couple things. Firstly, I need to use it for crud operations. I see examples for metadata, but none for crud. Secondly, the lightblue-client is being used, and so I would need a way to submit the SecurityContext via the client.
I suspect security context is going to be server side, not something the client could submit. Else it's not so secure. Yes, there are only metadata examples, but the idea is the same. For the tests, how is lightblue being used? Embedded, arquillian, docker, etc?
Embedded, so I do have access to the in-memory server. Maybe there is something we could take advantage of by being embedded?
It appears that the CRUD methods on AbstractMetadataResource all take the SecurityContext as a @context injected parameter, but that is not the case in AbstractCrudResource, So that is possibly one change that would need to happen.
Also in AbstractMetadataResource, I see where the SecurityContext is consulted, but it looks to be a different check than that of ClientIdentification in AbstractRestCommand. So even if the above were true, I think we would still be blocked at the same point.