Fedora's SOAP API has historically been split into two: API-A and API-M. The REST API, being resource-oriented, naturally isn't. And the control over which endpoints can be set to require authentication is inconsistent across the two. The old "Authenticate for API-A? Authenticate for API-M?" options no longer make sense when you look at Fedora's APIs as a whole.

Here's one way the situation could be improved.

  1. For the SOAP API (all read-oriented and write-oriented methods), always require authentication.
  2. For the REST API, on a per-verb basis (POST/PUT/DELETE/GET), offer the following options at install time:
    1. Proactive Challenge: Always require authentication.
    2. Reactive Challenge: Only require authentication if an un-authenticated request failed due to AuthZ rules.

NOTE: This is being tracked as FCREPO-668

  • No labels

3 Comments

  1. Filipe Correia

    Do you think that, in what concerns authentication and permissions, it would be doable to, in some way, converge API-A and the GET verb, and to converge API-M and the POST, PUT and DELETE verbs?

    This makes a lot of sense to me, as otherwise it feels a bit like I'm repeating myself when defining policies.

    1. Chris Wilper AUTHOR

      I think that would be a definite improvement, but I would actually like to get rid of the API-M/API-A distinction altogether, and just put it all at a single SOAP endpoint. Some of those methods are read-oriented (more analogous to GETs on the REST API) and some write-oriented (more analogous to POST/PUT/DELETE).

      The only reason I can think of to continue to have them at different endpoints (API-A and API-M) would be to have the ability to have the authentication challenge configured differently for each (e.g. require authentication for API-M but not API-A). I'm not sure how common/desirable this case is, though. Is it reasonable to expect that if people are working against the SOAP API, they could always authenticate?

      1. Filipe Correia

        I think I understand better what you mean now. On the long run, I'm more interested on the Reactive Challenge approach for the REST API.

        Is it reasonable to expect that if people are working against the SOAP API, they could always authenticate?

        For the use cases I've personally found so far, yes.

        For those that would prefer to provide anonymous access to the SOAP APIs, I guess the workaround will be to create an 'anonymous' user? Just trying to see what's the worst case scenario of always requiring auth.