Do the Cedarlings support the Cedar Templates? How to implement dynamic roles?

[0ba100]

I'm not seeing any sort of template support in the code, am I missing something?

[nynymike]

For info:

• Policy Templates
• Generalized Templates

So in order to support this, we'd have to add a way to add extra params to render the final policies? Can you provide an example of how you'd like to configure this in the Cedarling?

[nynymike]

I checked the notes, and this is on the roadmap, but we haven't done it yet. Any details you can provide about how you think it should work would be helpful.

[0ba100]

Thanks, I will write up why we're using it, and how we're thinking of using it. In the meantime, is the roadmap public or ordered?

[nynymike]

You can search Jans Issues for cedarling... that's the roadmap! We have slowed down a little because our lead developer was hit by a Russian ballistic missile. But we have two new team members who are engaged, and we're starting to prioritize the next round of enhancements.

[0ba100]

Our company has user-created roles. Using templates in the cedar scope allows us to have a unified policy that applies to every role. Here's an example policy:

permit (
  principal in ?principal,
  action == Namespace::Subsection::Action::"edit",
  resource is Resource
) when {
  principal.role.namespaceSubsectionEdit // Assisted by general templating in the future.
};

Our policy becomes sacrosanct, but still user modifiable on account of role settings. We would provide the active user's role to the PDP, and it would create a "template derived policy" allowing full decision making for the user using the derived policy.

Changes to the single policy would propagate to all roles without requiring extensive migration, and the client doesn't have to worry about which role is "active" when making authz decisions.

I hope that is helpful.

[0ba100]

I recommend this alternative gofundme link which does not require sign-in: https://www.gofundme.com/f/support-gluu-developer-oleh-bozhok-cedarling-coauthor

I hope he recovers, that efforts to support him are successful, and that he is blessed with fortune.

[nynymike]

IMHO, this would be faster, because you are removing the ABAC section of your policy:

permit (
  principal in Namespace::Subsection::Role::"namespaceSubsectionEdit",
  action == Namespace::Subsection::Action::"edit",
  resource is Resource
) ;

In the Cedarling, you can use the role mapping feature. Unfortunately, we have not 100% finished the docs, but here is what we currently have! But here is some more info:

1. Bootstrap property enables you to specify a role called CEDARLING_MAPPING_ROLE, where you would specify your group entity, like Namespace::Subsection::Role.
2. In the Trust Issuer Metadata, you would specify which token contains the role information. For example, it may be present in the Userinfo token, if it's sent as an OpenID Connect user claim. When the Cedarling sees this attribute, it will iterate the values, and create a Role entity (see step 1 above) for each Role, and add the User to that Role entity.

This page may also give you some insights into how and when the tokens are processed. BTW, Tarp has the Cedarling WASM in it, so you can test using that very quickly (running as a browser extension).

IMHO this would be faster and easier to maintain. You can also group your actions, so instead of saying
action == Namespace::Subsection::Action::"edit", say action in Namespace::Subsection::AdminActions ... that way, you're not having to hard code every single capability.

[0ba100]

Thank you. Our software allows users to create and modify arbitrary roles, so we cannot hardcode any roles, and each action will have a different approval process. The policy does not know the role at bootstrap time, nor will it until authorization requests occur from a signed-in user, and it instantiates a template.

Here's an example of what our logic may look like.

permit (
  principal in ?principal,
  action == Projects::Action::"edit",
  resource is Project
) when {
  principal.role.settings.projectsEdit == true
};

permit (
  principal in ?principal,
  action == Projects::Action::"view",
  resource is Project
) when {
  principal.role.settings.projectsView== true
};

permit (
  principal in ?principal,
  action == Projects::Action::"delete",
  resource is Project
) when {
  principal.role.settings.projectsCreateDelete == true
};

permit (
  principal in ?principal,
  action == Projects::Action::"create",
  resource is Team
) when {
  principal.role.settings.projectsCreateDelete == true &&
  resource.settings.allowCreateNewJobs == true
};

The users will be able to modify the permission at any time:

This prevents me from grouping the project permissions, or requiring the role to be known before making the first authz request.

I may still be able to use the dynamically created roles that you mention, in the absence of template support

[0ba100]

Hm, are you saying that each of our role permissions actually represent a role in themselves? This is quite interesting.

[nynymike]

So you have created a document, and any person with Role51 should be able to View or Edit it?

[nynymike]

BTW, did you see this design pattern in the Cedar docs: https://docs.cedarpolicy.com/overview/patterns.html#relationship

[0ba100]

I have created Role51, and any user on it should have relevant permissions on all projects:

I have seen that design pattern, the design patterns page was quite helpful. Our models don't currently have relationships quite like that, but we may in the future.

[nynymike]

@SafinWasi, any thoughts about the best way to design the policies for this?

[SafinWasi]

The way Cedarling (and Cedar) defines "roles" is specific to OAuth flows, as in we construct the "role" entity as a group of Principal entities based on what the role claim contains in the ID or userinfo token. As such:

entity Role;
entity User in [Role] = {
...
}

permit (
    principal in Namespace::"role1",
    action,
    resource
);

However, this approach does not work for the aforementioned use case, where the role name may be changed arbitrarily. In this case, the role itself must be defined as an attribute of the principal entity in the namespace:

entity Role = {
    someProperty: ...
};
entity User = {
    role: Role
...
}

And then we must use ABAC policies:

permit (
    principal is Namespace::User,
    action,
    resource
) when {
   principal has role && principal.role.someProperty == "something"
};

The catch here is ABAC is slower than RBAC where we are simply checking if the principal exists in a group. Furthermore, I don't know if Cedarling currently has support populating the role attribute like that since it was designed around the Cedar definition of roles as a "group of users."