-
Notifications
You must be signed in to change notification settings - Fork 13
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
Enable adding policies as object #52
Conversation
LGTM. Can you add simple tests to prevent regressions for upcoming commits? |
@henrydaly could you explain why you need to look at the datalog of |
@Geal good question! I'd be happy to explain. We are aware that until a biscuit signature is verified, the datalog scope is not verified. What we want to do is look into what's provided in an Let me give a bit more context:
If the above conditions are met, we authorize the request - simple enough. Now things get interesting. Let's say a user wants to access two resources in the same request (we allow manipulation of multiple resources - about as specific as I can get). In case both resources have the same public key, then fine - one biscuit will suffice. However, if the resources have different public keys, then the user must provide two different biscuits. Now how can we know which biscuit to use to authorize each request fragment? Let me explain request fragmentation via an example:
Now, if we get two biscuits, we could potentially just try to authorize each fragment with both biscuits and see if there's some combination that works. This I believe is poor engineering, and most certainly not scalable as we grow the size of fragmentation. Thus - if we can find out what the payload of biscuit 1 and biscuit 2 look like, we can infer which biscuit should authorize which fragment (by looking into the datalog of @KannarFr will do |
ok, so if I understand correctly, what you mainly need is finding out which token maps to which public key. There are nicer ways to do that:
Trying both keys should still be fine though, the signature verification is cheap enough |
@Geal Both your above suggestions are useful for sure, but neither quite fits our needs. Biscuit -> public key mapping isn't actually that hard to do, like you said signature checks are cheap enough. We know based on the user request what resources are being accessed, so it's easy enough to go retrieve the public key for the biscuit. Matching biscuit capability against the request fragment is the more difficult challenge.
|
@KannarFr Unit tests added |
@Geal WDYT? |
We aim to design APIs where it is hard to write unsafe code, so that's why I am wary of adding a way to extract and execute datalog at the UnverifiedBiscuit stage. @henrydaly could you precise some things?
|
@Geal we're not trying to execute any datalog from an UnverifiedBiscuit, only to introspect and see what has been specified. But let me try to answer your questions:
All I'm trying to accomplish in this PR is to enable querying datalog from an unverified biscuit. If the data is already available inside the library, why can't we query it? I didn't add a path for users to construct an authorizer from an unverified biscuit, only read the datalog inside. |
The difference may seem large enough, but querying and executing are not that different. Being able to query and check policies (even if it's some preliminary check) from UnverifiedBiscuit is something we explicitely want to avoid; in security related APIs, if there's a way to use it unsafely, someone at some point will use it without thinking 😅
right, that makes sense
ah, that's the bit I was missing, thanks!
so, kind of batching operations, ok
because you cannot trust the content of the token if the signature was not verified. If we add the key id to this library (which we have to do) there would be only one signature verification per token, no need to test every key.
Could you test what I was hinting at in my previous message:
From what you told me, this looks like a safe way to solve the issue (unless I'm still missing something, which is very possible) |
@Geal alright. I think this will work, but for sure will be less performant until we can have the key-id check. Any idea on when that will be available? Separately from the |
I'll look into the key id in the next few days. For add_policy, yes sure it makes sense to add it! |
@henrydaly as a follow up, the PR adding support for the root key id #53 |
It's now published under org.biscuitsec.biscuit at version 2.3.1 https://search.maven.org/artifact/org.biscuitsec/biscuit |
Our organization has built a client library on top of biscuit-java. As part of our library, we need the ability to do the following:
We've built our own conversion logic to biscuit-java datalog objects (e.g., predicates, rules, facts, etc) and wanted the same function to add policies. Today, we can only add policies as strings. This PR enables introspection of datalog in an unverified biscuit and also enables policy objects to be added directly, rather than requiring string parsing