Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] W3C Note - User Agent Authentication FORM elements

Expand Messages
  • Tyler Close
    ... So how important is application security to you and others on this list? Are there people on this list that implement business applications, or is it
    Message 1 of 49 , Mar 6, 2003
    • 0 Attachment
      On Tuesday 04 March 2003 01:52, Chuck Hinson wrote:
      > Tyler Close wrote:
      > >Switching to capabilities improves your GUI, your application
      > >design and your security.
      >
      > I'll take your word on the security bit. I'm not convinced of the other
      > two.

      So how important is application security to you and others on this
      list? Are there people on this list that implement business
      applications, or is it mostly open use applications?

      I request that the list owner open a poll on this question: "I am
      currently implementing a web-service that provides access to a
      business process. yes/no".

      > So then, I don't understand your comment from an earlier message:
      > <quote>... you're right, you wouldn't use this model to give everyone
      > their own URI to a single, shared, read-only resource. </quote>
      >
      > As far as I am able to observe, an awful lot of the web consists of
      > shared, read-only resources. Are you saying that access control isn't
      > necessary for shared, read-only resources?

      Often, access control does not make sense for a shared, read-only
      resource. To answer the question, you have to study the situation
      to determine the roles of the participants.

      In order for shared access to be an access control problem, it
      must be the case that *all* participants want to protect access to
      the shared resource. If any participant does not care about
      protecting access, the access-control mechanism is without
      meaning. This is the case in the WSJ example.

      When only a subset of the participants wish to protect access to
      the shared resource, the problem is a DRM problem.

      Typically, access to a shared resource is only an access control
      problem when the shared resource is modifiable. It is rare for a
      modifiable resource to be shared between more than two
      participants.

      > A more useful example would be something like
      >
      > https://www.bank.com/myaccounts/savings/register
      >
      > With http auth, I can give this URL to everyone who has an account at
      > the bank, and that URI means the same thing to all of them - the page
      > that shows the viewer the last 20 entries in their savings account
      > register.

      Ah, but that's not the question I asked you. Can you post a
      traversable link to an entry from *your* account history?

      > Note that I'm not suggesting that this is a good solution for accessing
      > bank accounts - it just illustrates the idea of a public, sharable URI.
      > My understanding of the capability model leads me to conclude that I
      > can't do anything like the above because every user would have to have
      > their own URI.

      Telling someone how to access their own resource is also easily
      done in the capability model. Using the graph that defines the
      structure of the web of resources, you can determine what path
      they need to follow. So, in a capability solution, you would say:
      "Starting from your main account page, follow the path:
      'savings/register/'." Using my web-calculus solution, you would do
      this by appending the query string "?path=savings/register/" to
      the main account page URI.

      > >The point of access control is to create private webs of
      > >resources, with finely controlled links between them. Capabilities
      > >are an excellent tool for implementing this.
      >
      > I dont disagree. But it appears to me that the private web that is
      > created is only useful to one individual. What about groups of people?
      > If the answer is that everyone in the group shares the same, private
      > URI, then how do I revoke access to just one member of the group. (I
      > suspect your answer to this is going show that I don't understand the
      > capability model after all.)

      I think you are still thinking about DRM scenarios. As I said
      above, it is rare for a modifiable resource to be shared between
      more than two participants.

      When you want to have revokable access to a shared resource, you
      do give each participant a unique URI for the shared resource. To
      revoke access, you revoke just the corresponding URI. This is no
      more complex than managing an ACL for the resource would be.

      > >>As a result, you've lost the ability for people to connect
      > >>those resources together in new ways to create new things on the web.
      > >
      > >Exactly the opposite. What you've done is empowered people to
      > >securely connect those resource that they want connected. The ACL
      > >model prevents this.
      > >
      > >Just as an example, why don't you post to this list a link to a
      > >withdrawal record from your online bank account. With the current
      > >interface, this is not possible: you can't do it without also
      > >posting the password for your entire account. If your bank account
      > >was implemented with a capability-based security model, posting
      > >the withdrawal record link would be no problem. Capabilities
      > >enable you to create links. ACLs prevent you from creating links.
      >
      > I'm not sure why. Assuming the withdrawal record has a URI, I dont see
      > why I couldn't do that using a non-capability-based solution. (I've
      > also just realized that we're probably using the word _link_ differently.)

      Does your bank account have a separate ACL for every addressable
      resource? Are you allowed to modify those ACLs? Are you allowed to
      introduce new principals into the ACL system? Are you allowed to
      delegate all of this authority to others? Typically, the answer to
      all these questions is 'no'. To support linking, all these
      questions have to be answered 'yes'. An ACL design becomes far
      too complex when it tries to answer 'yes' to all these questions.
      When the application becomes this complex, it becomes a playground
      for crackers. A capability security model supports fine-grained
      linking with minimal complexity.

      > >>So how do you establish an initial context (or whatever its called) in a
      > >>capability-based system without doing authentication?
      > >
      > >Your initial context is whatever set of URIs you start with. If
      > >your program is an XSLT stylesheet, your initial context is the
      > >set of URIs in the input XML document.
      >
      > But how do I (as a client) get that initial set of URIs without
      > participating in some kind of authentication process? What do I click
      > on (or reference) to get started?

      Are you asking how a new user gets added to an existing
      application? If so, the first URI is given to the new user in much
      the same way as a username/password is given to a new user.

      > Ok - I guess I meant an example of how you would solve it. What does
      > the URI namespace look like? How do you navigate among the various
      > resources?

      If you want a fully worked out example, I suggest something
      simpler, like the tradeable credit example in the web-calculus
      specification:

      http://www.waterken.com/dev/Web/Calculus/

      The schemas for all the resources used in this example can be
      found at:

      http://waterken.com/iou/

      > >Access control is about controlling what authority you hand out.
      > >DRM is about controlling how people use authority they have
      > >already been given.
      >
      > I wont contest your definition, but my impression is that most people
      > dont use that definition (rightly or wrongly).

      I agree that most people don't know the first thing about
      software security. I blame this mostly on the complexity of
      existing software security solutions. I think the simpler
      capability security model could change the status quo.

      > Controlling access to a
      > Resource (the R in URI) is about determining whether or not you are
      > allowed to perform an operation on that resource - are you allowed to
      > perform a GET/PUT/POST/DELETE.

      Actually, that's just a product of access control. Access control
      is about how you came to have the authority to perform a
      GET/PUT/POST/DELETE, how you exercise that authority, and how you
      delegate that authority to others. This is a subtle but very
      important distinction. The difference has caused great confusion
      and error for many people, even some very smart people.

      > Which brings me to another question. I understand that you control who
      > can access a URI by controlling to whom you give the URI, but how do you
      > control how they access the named resource. That is, how do you control
      > whether or not they can POST vs GET?

      One of the main design principles in capability-based security is
      that distinctions in authority be reified as different resources.
      If POST and GET provide different kinds of authority, they should
      be different resources, accessed through different URIs.

      This means that GET on a POSTable resource should only provide
      information about what to POST. GETing the results of POSTing
      should be a different URI. This means you've got one URI that
      provides read-access to the current state of the resource, and a
      different URI that provides the authority to modify the state of
      the resource. Most existing web-applications are already designed
      this way.

      Tyler
    • Seth Ladd
      ... I don t believe it is. The identity of a thing shouldn t be coupled to any Access Control List information I have about that thing. Another reason: try to
      Message 49 of 49 , Mar 22, 2003
      • 0 Attachment
        S. Alexander Jacobson wrote:
        > I'm sorry. I was waayy too strident (too little
        > sleep).
        >
        > Anyway, the question remains: Is it RESTful for
        > resources to be parametrized by authentication
        > information?


        I don't believe it is. The identity of a thing shouldn't be coupled to
        any Access Control List information I have about that thing.

        Another reason: try to write RDF statements about a bank account, where
        that bank account is identified in a relative way.

        Relative ID: http://example.bank.com/account

        You can't write anything about that account because to truely identify
        it, you need ACL information. And in the HTTP world, the authentication
        is done outside the URI.

        If you had an absolute ID for a bank account, then you can actually say
        things about it.

        Absolute ID: http://example.bank.com/account/12345

        Then, this becomes possible (in RDF):

        <bank:Account rdf:about="http://example.bank.com/account/12345">
        <bank:ownedBy rdf:resource="http://example.com/person/88888"/>
        <bank:balance>$1,334.23</bank:balance>
        </bank:Account>

        You can't do the above w/ the Relative ID. All the RDF statements would
        end up saying that *everyone* owns account http://example.bank.com/account.

        This is all true, because HTTP's authentication is done at the protocol
        level, and independent of the URI. The ID of the thing you are trying
        to operate on is not affected by any ACL information.

        Now, having said that, this is a perfectly valid Absolute ID:

        http://example.bank.com/account?owner_id=88888

        But, of course, not as friendly w/ some caches and search engines. And,
        you still have to supply a password (or some authenticating token).

        Hope that helps,
        Seth
      Your message has been successfully submitted and would be delivered to recipients shortly.