Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: add p/demo/authctx #1244
base: master
Are you sure you want to change the base?
feat: add p/demo/authctx #1244
Changes from 10 commits
be18314
a4052cf
c51bf2f
b54edce
77567dc
0ac7ce4
8f185d5
6a96cfa
892ead8
0c25c14
93b153c
19e86b6
bf4fb3c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can an AuthContext authorize an action without knowing from whom the action comes from?
Is this supposed to return true all the time or is it a stub?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"correct auth is expected to be passed in as context"
So I guess that makes sense, but something seems off.
An authorization should be of both the object/caller and the subject.
You can assume the caller (more on that below) but still there is no subject.
Upon what is the action authorized?
It could be a naming issue, s/action/request/g for example would work, with request.action and request.subject.
Something about this general approach feels weird though.
Here's an analogy:
In a secure facility such as a building with access controls,
you have an identity card, which you swipe onto sensors, to open doors.
Wouldn't it make more sense to just pass around a Context which includes self identity, and to have a black box AuthControl.Authenticate(caller/subject, object, more action data)?
I don't see the benefit of the assume-the-caller AuthCtx that is exposed to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, let me explain my initial idea for this package:
Think of
AuthContext
likeJWT
but simpler. It's a way to prove that something came from a trusted source and can be used for authentication. It allows you to pass around authentication information securely and preserve authenticity.In a
JWT
, you have scopes or roles, but it's mainly used to manage permissions, not all the access control rules of an app.Another analogy I like is sudo. When you're a regular user, you have limited permissions. But when you use sudo, you temporarily get more power. However, you can configure sudo to only give you specific powers for certain tasks (scopes). The final app still checks if you have the right permissions, and sudo is responsible to create the
AuthContext
.AuthContext
also has the advantage of being storable. Instead of just storing an address to represent an owner, you can store more context. This is useful when you want your system (like a book/boards) to be usable by different accounts, contracts, and delegates. No need for boilerplate code on your realm.Orig
/Prev
AuthContexts have a default scope of "all," but when you delegate rights, you can limit them. There's also a helper to change (drop privileges) on anyAuthContext
, includingOrig
/Prev
ones.In short,
AuthContext
isn't just for access control lists (ACLs). Use tools likep/acl
for that. For delegated contexts, scope is as important as ACLs. While ACLs verify an owner's actions,AuthContext.IsAuthorized
checks the caller's rights in the current situation.Now, I see two main directions:
AuthContext
as it is, making it better at context management, but not a complete ACL solution. It's more of a flexible authentication context for writing apps with less boilerplate.Possible next steps (things I plan to consider/hack on):
authctx.IsNative(ctx)
to determine where the AuthContext comes from.IsAuthorized
checks through closures.p/acl
library and make it interface-based.IsAuthorized
toHasScope
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to condense my general understanding here.
If it's a restrictor, then why not just fail early instead of wrapping contexts? For example, if Bob orig caller calls some realm logic (scoped to realm permissions) which calls performs some action on a Book, why not just fail early when the action can't be performed by Bob? And if Bob is allowed, then why not fail early when the realm logic is not allowed?
It seems to me this is merely delaying logic that could be performed immediately into a chain of callbacks, and what's the point of that? I don't see the benefit.