Tuple Explorer - Conditions

Okta Fine Grained Authorization
1

Is there a plan to be able to include conditions in the Tuple Explorer so that those can be created from the UI?

Trying to create one from the Python SDK and its just throwing me a 400 error and I am honestly not sure what I am missing here.

2

Hi @stephenbawks1

Re: Tuple explorer, yes, we’ll do it later this year.

The Python SDK should work fine. Can you paste the code and the error you get?

You can also try the CLI, or using Visual Studio Code to author models + tuples + assertions instead of the Dashboard .

Let me know if that helps

3

One more bit of feedback. In the tuple management UI, it has “Relation” being the last field but everywhere else relation is always the second field.

How the “user” relates to the “object”. Just feels backwards in the UI and relation should be the second field and not the third. Kind of reads like the “user” “object” is related.

4

Thanks Stephen! Yes, I feel that pain sometimes too.

That order helps completing the tuple in the UI better. We can give you a list of relations of a type. If we ask for the relation in the second place, we’ll need to list all relations for all types that you can assign a specific user type to, which would be pretty large.

The way to read it is “user X is related to object X as Z” (“user:1 is related to document:1 as a viewer”).

5

Yah I am using the CLI and the VS Code to do testing and that has been working out well. I am not seeing a way, or at least not a documented way, to test conditions however in the extension.

Updated: Actually I did figure out a way to test conditions.

1 Like
6

Is there a way to have a condition to check an IP address, but I want to check against a list of IP CIDR blocks. We have several team member networks and I would like to have a condition to check to see if the IP address is in one of those blocks? Wondering if I can do something like this below where the cidr is a list.

      - user: team_member:internalteammember@example.com
        relation: admin
        object: api:account_admin
        condition:
          name: in_company_network
          context:
            cidr: ["1.2.3.0/21", "2.3.4.0/21"]
    check:
      - user: team_member:internalteammember@example.com
        object: api:account_admin
        context:
          user_ip: 1.2.3.12
        assertions:
          create_account: true
7

In the context of this example, you can change the condition to be

condition in_company_network(user_ip: ipaddress, cidr_list: list<string>) {
     cidr_list.exists(cidr, user_ip.in_cidr(cidr))
  }

You’d write tuples like

    - user: "organization:acme#member"
      relation: "ip_based_access_policy"
      object: "organization:acme"
      condition: 
        name: in_company_network
        context: 
          cidr_list: 
            - "192.168.2.0/24"
            - "192.168.0.0/24"

Would that work?

8

Just tested and that works! Thank you.

9

I have not tested this, but was curious if you can reference conditions that would be in a parent module in sub-models?

10

Yes, you can do that

11

Additional follow up on this. If I wanted to centrally control a list of CIDR blocks like this so that people are not having to specify those when writing a tuple to the database, is there any way I can do this?

Have variable where I can control the CIDR blocks and the condition would just reference that variable.

12

The options you have are:

  • You store them in the FGA database as part of the context for a condition
  • You send it in each Check request (you’d send the CIDR + the user’s IP address). In this case, you could get the CIDR from the environment and use it when calling check

Does this help?

13

Ideally I want to be able to store them centrally so that teams are not having to specify these themselves. Plus there is the thought around being able to change the central list of approved CIDR blocks without having to rewrite each tuple that may be referencing those.