Selectively allow anonymous access

[dnndevelopernc]

Is it possible to white list one or more endpoints?

for example: I would like to require authentication for all mutation and queries except for Login.

Currently we authorize each mutation individually - we fear forgetting one will ship and endpoint with open access. The query mutation we AuthorizeWith at the root level therefore it catches all endpoints.

If this is not possible with the current implementation, I am happy to create a PR but how would this work? Instead of AuthorizeWith on an endpoint have DisableAuthorization() ? This could add metadata that is inspected during evaluation to bypass root level policies. What are the drawbacks to this approach?

Update
Took the initial approach of removing operation level validation and the fields now inherit parent policies if they are not flagged a public.

Example

[Fireblade954]

Currently u could also just do it like .AuthorizeWith(""); or some other non existing policy name. If the policy doesnt exists the user is also authorized.

[dnndevelopernc]

@Fireblade954 that is no longer allowed with this issue fixed (PR merged) #15

Thank you for the suggestion

[OpenSpacesAndPlaces]

Easiest way I found to-do with was:

(at whatever levels you need)

new FieldType
{
...
Metadata = dRules // This field lets us define properties anything in the resolver pipeline can use
...
}

Usage sample here:
#6

But this one of those - roll it like you need it cases.

[sungam3r]

I think the issue of using the policies found in the GraphQL document is much broader and in some way relates to #6. Now I see the problem that it's not just enought to make auth check immediately when walking over AST. There should be some new component that accumulates all found policies to apply and then ... do something with them. In your case this component should filter policies to allow some priority model. In other cases it can modify/add policies, I don't know exactly. Such a view will allow not to mix different tasks in a bunch. One task - find all appliable checks with theirs context from input document. Another task - use somehow that information before performing checks. Ping @joemcbride @Shane32 .

[sungam3r]

In other words, the need to fulfill the defined policies depends on the state of the entire AST.

[sungam3r]

Or how do you like this solution - allow to remove validation errors from ValidationContext. Imagine AuthorizePublicRequirement that may check AST to see if it can safely put away validation error if INode from that error points to parent query/mutation/etc. Implement that "safely" may be a bit tricky though.

[sungam3r]

the need to fulfill the defined policies depends on the state of the entire AST.

I think this is the main thing.

[Shane32]

I’m not sure I understand exactly what you suggested @sungam3r . I would comment on the original issue/suggestion, and say I agree, but I’m not exactly sure how. I think of ASP.Net where you can specify AllowAnonymous to make a specific action accessible regardless of the authentication attribute on the parent.

For GraphQL.NET it would be nice if all those conditions are precomputed when the schema is built to save on execution time at runtime.

[sungam3r]

Yesterday I reflected a lot about possible ways to implement. All decisions coming to the head, one way or another were associated with difficulties. Difficulties not only technical details, but also design. As a result, I came to the conclusion, which seems to me the easiest solution to the problem - no need to invent any sophisticated ways to override policies. The easiest, understandable and least erroneous way is to develop your schema in accordance with the required policies:

type Query {
  public: PublicApi!                no authorization here 
  authorized : AuthorizedApi!    authorized with some requirements
}

type PublicApi {
  login(input: LoginInput!): LoginResult!
  help(message: String!): FeedbackResult!
  otherPublicFields: ...
}

type AuthorizedApi {
  author(input: AuthorInputType!): String,
  otherFields: ... 
}

These are so called namespace-types or role-types. Another example:

query {
  viewer {
    getNews
    getAds
  }
  me {
    nickname
    photo
  }
  admin {
    shutdown
    exposePersonalData
  }
}

In this case, several qualities are achieved at once:

1. Schema is well-decomposed
2. Authorization requirements for fields are intuitively understandable.
3. No changes in Authorization project at all. The implementation remains simple.

I could speculate some time about how to change the mechanism of policies checks, but I strongly doubt that this will lead to a decent solution.

[sungam3r]

@dnndevelopernc I close this for now. Reopen if you have further questions.