844600078504951838 #spicedb

Channels

derwolfe

11/09/2021, 4:38 AM

hey! I've started trying to map out an abac-y style of authz. I'm used to a policy system that allows users to either specify an attribute or default to that attribute being open. A teammate pointed me to the open ABAC ticket and paper which was helpful too . https://play.authzed.com/s/XDTERfryivgG/expected is my current playground. I'm thinking I've made at least some mistake attempting to build out the group - I'm a bit confused by the need to build the state space of possible attributes in advance, but I suspect that is a by product of how I've structured my group definition rather than something spice imposes. Should I expect to be able to make a single request for check_permission to ask the following questions: `can app foo in us-east-1 in app test view doc`; or ‘can app bar with super account and super region view doc’ or would this just require distinct checks for each attribute?

Jake

11/09/2021, 2:24 PM

in east-1

something intrinsic to the requirements to view doc or is that just another attribute you want to check about the application?

Jake

11/09/2021, 2:25 PM

put another way: is the doc only viewable by apps in

east-1

Jake

11/09/2021, 2:34 PM

most things that only involve a single subject and object can be modeled using relationships and only require a single check call

Jake

11/09/2021, 2:34 PM

but if you wanted to know the separate queries

does us-east-1 contain app1

and also

does app1 have view permission on doc1

then those would be different checks

Jake

11/09/2021, 2:35 PM

if it's intrinsic you can usually model it with a relationship and intersection like so: https://play.authzed.com/s/ZEkWmBasI5vz/schema

derwolfe

11/09/2021, 3:01 PM

hey! thanks - it is only a property of the caller now, where the policy would say allow the list of apps with foo/us-east-1/test, bar/us-west-2/dev

derwolfe

11/09/2021, 3:04 PM

out of curiosity, are there any papers on the identity service (Gaia I think?) that describe how it coalesces complex identities to single subjects?

Jake

11/09/2021, 3:05 PM

no papers that I know of, but what do you mean by "complex identities"?

Jake

11/09/2021, 3:07 PM

AFAIK you can think of gaia like an internal Auth0, it can interpret complex evidence of a user's (or role account's in the case of non-human users) identity and normalize that into a single subject reference handle (a unique int in the case of google)

derwolfe

11/09/2021, 3:07 PM

got it, that makes sense

DefinitelyNotSam

11/09/2021, 5:14 PM

Lol hi!

vroldanbet

11/10/2021, 12:16 PM

Hi 'yall! Was having a look at https://github.com/authzed/spicedb/issues/1 and was looking at workarounds until support for "public" keyword is added. Joseph describes an approach in "Provide guidance on how customers can implement it themselves". I found that forcing callsites to perform 2 checks is flawed, as it leaks implementation details, could be easily overlooked by devs. I have an alternative that, while it also comes with its own set of tradeoffs, addresses the "multiple check", wanted to bounce it and see what your thoughts are. Didn't actually try it out in the playground

definition user {}
definition allusers {
  relation member: user
}

definition video {
  relation viewer: user
  relation public: allusers

  permission view: user | public -> member
}

allusers:0#member@user:userA
video:X#public@allusers:0

if authzed.check(video(‘x’).view, userA):
  ...

Tradeoff: - data redundancy: a relation must be added for each new user in the system - anonymous users need to be modelled as a singleton user

ecordell

11/10/2021, 1:26 PM

That's definitely an option and (as you say) removes the burden from the check-writer to know about what objects might need to be checked for public. I wrote it up in playground, since I thought it might be a useful example to share with anyone trying to do this before the public proposal is implemented: https://play.authzed.com/s/DybMLyaLcX4t/schema This is basically a user group, where you add every user to a default

all

group (i.e. rename "allusers" to "group" and you can make all the same checks, but now it's not a singleton type)

vroldanbet

11/10/2021, 1:32 PM

Yup, it's indeed just another group! 💯 Thanks for the feedback. Obviously not awesome to write several million relations to model that in our system, but at least unblocks the modelling of our domain for the time being. I can add this as a comment to the issue for discoverability it it made sense! 🙇🏻‍♂️

Jake

11/10/2021, 1:32 PM

Do you have a strong opinion on any of the public proposals?

vroldanbet

11/10/2021, 1:45 PM

I think the latter option (* operator) is the most ergonomic so far. I'm not sure about the technical reasons why "publicable" is necessary here tho, and it seems rather specific, when there could be different levels of visibility in an application (e.g. github's internal visibility). Something it does not address is non-authenticated users, but I guess a workaround is to model the anonymous user as a singleton user.

DefinitelyNotSam

11/10/2021, 1:45 PM

Is this the proper place to ask implementation questions?

Jake

11/10/2021, 1:46 PM

Sure!

DefinitelyNotSam

11/10/2021, 1:51 PM

Awesome! I'm currently a little unclear on the deletion op. Currently I am using the Go SDK and the deletion op fails to delete. I have tried using the zookie and full_consistency on the permission check after the deletion op. This is the relation that was created (using the wrappers I have implemented)

{
    ResourceType: Client,
    ResourceID: "test_client1",
    Relation: ClientRelationAdmin,
    SubjectType: User,
    SubjectID: "test_user1",
}

When deleting this relation I am passing all of this info. The only part that I am iffy on is I include the relation type in the

RelationshipFilter.OptionalRelation

field not the

SubjectFilter.OptionalRelation

Am I missing something

Jake

11/10/2021, 1:53 PM

Can you show the deletion call?

DefinitelyNotSam

11/10/2021, 1:53 PM

Ya sure

Jake

11/10/2021, 1:53 PM

Is this against spicedb or Authzed.com?

DefinitelyNotSam

11/10/2021, 1:53 PM

SpiceDB

DefinitelyNotSam

11/10/2021, 1:54 PM

// create base request with default options (optional fields here are strings; they can be filled even if they were not passed)
    req := pb.RelationshipFilter{
        ResourceType: string(relation.ResourceType),
        OptionalResourceId: relation.ResourceID,
        OptionalRelation: string(relation.Relation),
    }

    // conditionally include a subject filter if values were passed
    if relation.SubjectType != "" {
        // include the subject information
        req.OptionalSubjectFilter = &pb.SubjectFilter{
            SubjectType: string(relation.SubjectType),
            OptionalSubjectId: relation.SubjectID,
        }
    }

    // execute permission removal call
    res, err := db.DB.DeleteRelationships(context.TODO(), &pb.DeleteRelationshipsRequest{ RelationshipFilter: &req })

DefinitelyNotSam

11/10/2021, 1:55 PM

the variable

relation

in this code block is the above struct that I sent