akajla

7 ms·

1.
ExtendDB – open-source DynamoDB-compatible API adapter with pluggable storage(github.com)
2 points by akajla 4mo ago|0 comments
2.
A New Browser War(akajla.com)
2 points by akajla 1y ago|0 comments
3.
by akajla 2y ago
I think one major difference between the Zanzibar implementations that are out there is support for the 'zookie' consistency token (as mentioned in the original paper). OpenFGA afaik doesn't implement zookies yet[1]. With zoo
4.
by akajla 3y ago
The specific challenge with authz in the app layer is that different apps can have different access models with varying complexity, especially the more granular you get (e.g. implementing fine grained access to specific objects/resourc
5.
What Is Google Zanzibar?(warrant.dev)
3 points by akajla 3y ago|0 comments
6.
Warrant Launch Week – Authorization Model Templates(blog.warrant.dev)
3 points by akajla 3y ago|0 comments
7.
Warrant Launch Week – Day 3 (Consistency, Performance and Multi-Region)(blog.warrant.dev)
3 points by akajla 3y ago|0 comments
8.
by akajla 3y ago
The article references the F-35A which is the conventional take-off/landing variant whereas the VTOL variant is the F-35B.
9.
by akajla 3y ago
We offer this natively within Warrant's authz service: https://docs.warrant.dev/guides/feature-flags/
10.
by akajla 3y ago
You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents&
11.
by akajla 3y ago
What we're building at Warrant ( https://warrant.dev/ ) might work for a lot of what you mentioned including APIs to build and manage multi-tenancy, groups, users, orgs/tenants. Note - Warrant is an authz engine so
12.
by akajla 3y ago
They might not be the exact same concept but they're definitely related. I'd argue feature flags, authorization, and pricing tiers/entitlements all make up modern 'access control' and 'access management'.
13.
OWASP API Security Top 10 2023RC(owasp.org)
1 points by akajla 4y ago|0 comments
14.
by akajla 4y ago
> I want to include role (or other) information directly in the token for the sake of convenience This works up until a certain point. Once you get past simple RBAC to more fine-grained (resource-based) authz, jwts don't scale: htt
15.
by akajla 4y ago
The self-service dashboard is scoped only to privileged users (typically account/tenant-specific admins like IT admins) that have a specific permission.
16.
by akajla 4y ago
Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https:&
17.
by akajla 4y ago
Disclaimer: I'm the founder of an authorization company [1] & previously worked at a large, enterprise/SaaS company so basing my comment on my experiences. Your considerations and things you need to worry about will vary great
18.
Show HN: API Runner – A tool for testing APIs written in Go(github.com)
3 points by akajla 4y ago|0 comments
19.
SoCal Infra and DevTools Companies(github.com)
4 points by akajla 4y ago|0 comments
20.
by akajla 4y ago
Thanks! There's a lot to build out on the authz & access control side so that's our focus for now. But we've built Warrant in such a way that it plugs-in with any existing or new authn solution including homegrown, Auth0,
21.
by akajla 4y ago
We have thought about it but still evaluating. In general, our thought here is that in case we go out of business, customers should be able to continue using the software with access to source and some level of temp support. We'd codif
22.
by akajla 4y ago
This is all very useful, thanks for your feedback! > 3.) Supporting staging/local dev environments with as little additional dev work would be awesome. You may already accomplish this, didn't go deep into the docs. We currently
23.
by akajla 4y ago
Thanks for the feedback! Hoping my responses will be quoted properly: > I share other folks concern regarding a remote api call for authentication, but I think your Edge Agent solution would address most of these concerns. I’d thus hope
24.
by akajla 4y ago
Hear you on this, as mentioned in other comments, we have the edge agent to address performance/reliability concerns and are definitely looking into providing full on-prem/self-hosted options.
25.
by akajla 4y ago
If you're using the cloud service directly, it's possible. But with the edge agent, all access checks will continue to function even if the cloud service is hard-down. And as others have mentioned, we're also planning to offe
26.
by akajla 4y ago
Very valid concern. We built the edge agent( https://github.com/warrant-dev/edge-agent ) specifically for perf and reliability concerns. It's designed to run in customer infra with built-in storage (currently in-mem
27.
Launch HN: Warrant (YC S21) – Authorization and access control as a service
115 points by akajla 4y ago|60 comments
28.
by akajla 4y ago
I've seen it implemented in exactly this fashion. You can even hook up Stripe (or any other checkout system) in such a way that a successful payment triggers the "feature upgrade" on the back-end and subsequent interactions w
29.
Storing Access Policies in Policy Files vs. a Policy Database(blog.warrant.dev)
2 points by akajla 4y ago|0 comments
30.
by akajla 5y ago
For this type of background job use-case (ex. some backfill, processing etc), I would think the main reason for authn/authz would be to ensure that only the background job process can read and edit the appropriate user data. In that ca

More ›