Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a way perform integration tests that use entity permissions #13

Closed
dcrissman opened this issue Apr 2, 2015 · 6 comments
Closed

Need a way perform integration tests that use entity permissions #13

dcrissman opened this issue Apr 2, 2015 · 6 comments

Comments

@dcrissman
Copy link
Member

@dcrissman dcrissman commented Apr 2, 2015

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.

@jewzaam

This comment has been minimized.

Copy link
Member

@jewzaam jewzaam commented Apr 6, 2015

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.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Apr 6, 2015

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.

@jewzaam

This comment has been minimized.

Copy link
Member

@jewzaam jewzaam commented Apr 8, 2015

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.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Apr 8, 2015

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.

@jewzaam

This comment has been minimized.

Copy link
Member

@jewzaam jewzaam commented Apr 9, 2015

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?

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Apr 9, 2015

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.

@dcrissman dcrissman changed the title Need a way to test permissions without a cert Need a way perform integration tests that use entity permissions Apr 9, 2015
@dcrissman dcrissman closed this Mar 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.