Skip to content

Client Authentication Discovery

Jump to bottom
Henry Story edited this page Feb 1, 2016 · 7 revisions

How does a client find out which methods it is allowed to use, and which methods it could use to authenticate? There are a number of pieces to this problem, some of which have not been clearly resolved yet.

Allow Headers

The LDP Spec requires (please verify) that the server specify for each resource what methods are allowed on that resource in the Allow header.

The current LDP spec left authentication out of bounds. So as a result it is not yet clear what happens in case of authentication. This will require careful reading and hermeneutics of a number of specs in the IETF and W3C space, and then perhaps some new guidelines for how this should work.

Authentication adds the following problem:

  • should the server show what methods a resource is able to deal with no matter how the client is authenticated?
  • or should the server show those methods a resource will allow given the credentials provided by the user at that point in time?

Some things to take into account:

  • Server/client ease: Clearly it would be easiest for the client if it could just rely on the Allow header to work out what methods it is allowed to use to interact with that resource. On the other hand it is a lot more work for the server to calculate for each request what the client is allowed to do on that resource as authenticated. Arguably that may be something that can be optimised, but it would be important to calculate the cost.
  • Even if the server specified the methods allowed for a client as authenticated at that point, the client would then need a way to find out what it would be allowed to do where it to authenticate.

Web Access Control files

So the second way for the client to work out what it is allowed to do on is for the client to follow the rel=acl link header and read that file to calculate all its options, the same way the server does it. The ACL need not be publicly visible in all circumstances for this to work. If a set of resources is only visible to members of a company the acl resource need only be visible to them too. Usually though an ACL will describe restrictions over and above those able to view the ACL. If showing any information about the ACL is a problem then the fallback position is the previous section of using the Allow headers only.

Here is an ACL that allows one user to edit all files in a domain using patterns of resources as described in Regexes in ACLs, and everybody to read all acls in that domain. Any resource that wishes to follow that acl need only wac:include it.

[] acl:accessToClass [ acl:urlPattern [  acl:base <.>; acl:match "*.acl" ]] ];
   acl:mode acl:Read;
   acl:agentClass foaf:Agent .
[] acl:accessToClass [ acl:urlPattern [  acl:base <.>; acl:match "**" ]] ];
   acl:mode acl:Write, acl:Read;
   acl:agent <card#me> .

Having the client use Web Access Control files can be very powerful. It would allow one to solve the NASCAR problem for example, since the client could use the ACL file to calculate what groups of people it belongs to that are allowed to use a specific method, eg POST, and in combination with a WWW-Authenticate header field (though this is only available in a 401) to work out what identities it would be worth using to access the resource in question, given a list of identities available to the client. (see issue 54 on Nascar in solid-spec)

This requires the client to reason about ACL files, but that type of library need only be written once to be used by all applications.

Conclusion

There is a series of methods that can be used by the client to discover the authentication level it would need to use to be able to access a resource, from the basic/stupid 401 with no explanation, to more advanced uses with ACL files.

Clone this wiki locally