Add OpenFGA Support

[rwinch]

We should look into adding OpenFGA support See https://openfga.dev/

Some NOTES for myself:

• We can use Testcontainers support for starting the openfga Docker image
• We should provide a conventions based approach for loading the authorization model and data similar to how we support loading schema and test data into a database. To take it a step further, perhaps there could be an external liquibase style library for OpenFGA that Spring could leverage.
• An example of what we might do is here
• A working sample is at https://github.com/jimmyjames/fga-spring-examples

[aaguiarz]

Hi @rwinch

It would be awesome! Let me know if we can help in any way.

[Crain-32]

@rwinch I've looked into this for work before, wouldn't mind helping out.

What paths have been discussed? Is this an integration to the hasPermission SpEL? Or the Domain Object Security?

[jimmyjames]

👋 Hi @rwinch,

We (at OpenFGA) would love to help with this! I am also curious about potential paths here, similar to @Crain-32 an extension to the hasPermission SpEL comes to mind, or perhaps a custom named PermissionEvaluator, but I'm interested in other potential paths.

I think any support should also provide an easy way to write authz data to OpenFGA; the OpenFGA Java SDK can be used to handle both read/writes, perhaps it could be leveraged?

[rwinch]

Hello everyone!

Sorry for the delayed response. We haven't outlined how the features would work yet, but I'm open to suggestions. The more concrete the suggestions the easier it will be for me to understand.

We will likely use a library like OpenFGA Java SDK to do most of the work and provide implementations of Spring Security interfaces (perhaps AuthorizationManager) to provide Spring Security specific features using OpenFGA.

[Crain-32]

I think part of the issue with concrete suggestions is it is rather hard to figure out where to fit the concept (for me personally) in Spring right now.

For example reading the documentation on the ACL Module, it almost sounds like OpenFGA would be a good fit there. However looking at the Repository the code has only been maintained, which is fantastic from a library standard, but concerning if looking to add to it.

I think you could model OpenFGA decently okay in a custom PermissionEvaluator, however that is only the Authorization Decision, whereas the updating/creation of the Authorization Tuples can't be modeled corrected there. Meaning the creation of another module (Spring-OpenFGA?) or some other type of interface would be required to really make sure the creation/update portion of the SDK is available to users in a Spring like fashion.

[rwinch]

@Crain-32 Thank you for your response.

At this time, I think that we'd probably implement the authorization in a new AuthorizationManager interface because it is the modern API for authorization in Spring Security that allows returning a richer response.

I don't think we would provide code for managing the relations because we typically only provide integration with Spring and the management of the relations can be done with the existing OpenFGA Java SDK.

I'm curious how you imagine using OpenFGA in a Spring application. For example, do you think that you would use it in method security? If so, what do the use cases look like?

Do you think it would be used with web based authorization? Again, what would those use cases look like?

[jimmyjames]

@rwinch and @Crain-32, like the conversation here!

If I take a step back a bit and consider the use cases, I believe these are some of the key use cases that come to mind:

1. Provide a way to pre- (and maybe post? need to think of specific cases where post-authorization would make sense) perform an FGA check via method security. For example, does user X have permission Y for object Z.
2. Some sort of way to write authz data back to FGA either through the OpenFGA SDK either directly or through a wrapper we provide in Spring. I think this would have to be directly coded in the application on a case-by-case basis, as it is application specific.

Perhaps this isn't applicable to a direct integration in Spring Security, but it might provide insight into use cases - if I were looking to integrate within my company, I'd consider:

• Creating a Spring Boot Starter that initializes an OpenFGA client that can be injected into my app, so that I can write authz data when needed
• Some sort of new annotation and Aspect that would intercept annotated methods and perform the configured check, to either allow or deny access

I'm not familiar with direct implementations of AuthorizationManager but I will look into it!

Also perhaps worth looking at is the Quarkus OpenFGA extension; I've not looked at it deeply but it may provide some insight.

[Crain-32]

@rwinch I personal lean towards the Method Security approach, which is why I instinctively went for a custom PermissionEvaluator. From my limited perspective if I adjust my authz in the HttpSecurity bean I'd stick to simply grant checks against the Authentication, partially because the Relationship based checks that FGA are good at would be hard to express in the current Security Matcher. I believe that's currently handled by the GlobalMethodSecurityConfiguration, and I'm honestly unsure of the usage of the AuthenticationManager within that class. I'd have to give it a more thorough review.

Which also moves over to @jimmyjames comment, as if we focus on how the mapping between the Method Security Annotations and the FGA API works, we can probably rule out some options pretty quickly. If we find hasPermission lacking or wrong, I'd honestly say that having the module introduce a new hasRelationship SpEL would work. Since that would mean no special annotations or handling, we'd just get Pre/Post Filters and Authorize out of the box. Along with Native Compilation support if memory serves.

For letting the client access the OpenFGA API, I think as we push forward it would be useful to see if the SDK could have a Spring Flavored Client. I saw the OpenApi Generator auto-generated comment when I checked out the SDK yesterday, and I have an understanding that OpenApi supports Spring Clients. This would resolve the questions around "how" the user can get access to the Client, as they can just inject it as a bean where they see fit. Plus some other QoL stuff that isn't important at this stage of the conversation.

[aaguiarz]

@rwinch @Crain-32 we identified a few possible alternatives for implementation, would you be OK with you to jump on a quick all in the following days to align on the best path forward?

Besides the implementation questions above, which we are wondering where is the best place for the integration code to live.

[rwinch]

I'm curious how much of this support should be OpenFGA specific. User's can use @PreAuthorize with SpEL expressions to check permissions. For example:

@Component
class OpenFga {

    public boolean check(String user, String relation, String _object) {
        var options = new ClientCheckOptions()
          .authorizationModelId("1uHxCSuTP0VKPYSnkq1pbb1jeZw");

        var body = new ClientCheckRequest()
          .user(user)
          .relation(relation)
          ._object(_object);

        var response = fgaClient.check(body, options).get();
        return response.getAllowed();
  }
}

@PreAuthorize("@openFga.check('user:anne', 'reader', 'document:Z')")
public void securedByOpenFga() {

}

With gh-14480 we should be able to refine that quite a bit:

@Retention(RetentionPolicy.RUNTIME)
@PreAuthorize("@openFga.check({user}, {relation}, {_object})")
public @interface OpenFga {
   String user();
   String relation();
   String _object();
}

@OpenFga(user = "'user:anne'", relation="'reader'", _object = "'document:Z'")
public void securedByOpenFga() {

}

I'm not saying we don't need explicit OpenFGA support, I'm just not sure at this point. I think some concrete usecases will help us to flush things out.

What I'd like to see is someone (perhaps collaborate on) setting up some samples of use cases in a separate repository. We don't need any security, but we should have TODO comments (or better yet tests) to describe how we want things to work. Then we can start to fill in the pieces.

I've also put together gh-14595 which is a list of method security enhancements I've been thinking about. I think that these tickets will help OpenFGA support as well.

[aaguiarz]

Thanks @rwinch !

We were thinking of exploring the approach below as it seemed to provide a better developer experience, using custom annotations.

@Service
public class MyCustomerService {

    @FgaCheck(object = "#id", userType = "user", objectType: "doc", relation: "viewer")
    public Customer readCustomer(String id) { ... }
}

If I understand correctly, it seems pretty similar to #14480.

Would it make sense to start with @PreAuthorize and once #14480 is available, also support that approach?