Skip to main content

Subject

A Subject is an entity to which access can be granted, such as a dataset.

    datasetId stringrequired

    A dataset which a principal may or may not have access to.

    modelId stringrequired

    A model definition which a principal may or may not have access to.

    modelFileId stringrequired

    A model file which a principal may or may not have access to. In practice, this likely matches the model itself.

    fineTuneJobId stringrequired

    A job, in the sense of an async/worker job. Ex: a user may be able to see a fine tune job but not edit/cancel it.

    operationId stringrequired

    An operation. Ex: a user may be able to see datasets without their full lineage (as operations).

    targetPrincipal

    object

    required

    A Principal acting as a Subject to express user management actions and transitive access. See note in Predicate.

    userId stringrequired
    organizationId stringrequired

    organizationRole

    object

    required

    A role specified in the context of a particular organization. Can be used as its own Principal as a convenient way to define groups of permissions.

    organizationId stringrequired

    role

    object

    required

    A role for a principal (likely a user) within an organization. Mostly used for Authorization. Anticipating the need for more roles here, we space out the values to leave unused numbers so that we can add more later while preserving the natural ordering of permissions. We don't prescribe specific authorizations here despite the suggestive names.

    basic booleanrequired

    "Basic" permissions.

    editor booleanrequired

    "Editor" permissions.

    owner booleanrequired

    "Owner" permissions.

    isWildcard booleanrequired

    When true, this flag dictates that the Subject represents the entire resource type. The id field must also be a literal "*" or else we should fail validation, to avoid magic strings or unexpected auth configurations. A wildcard subject is especially important for creating new resources of a type (CREATE), and listing (LIST), since in each case there is no existing ID to base authorization on.