RE: "Onion model" explained

+1

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624


                                                                                                                                  
                      Hal Lockhart                                                                                                
                      <hal.lockhart@ent        To:       "'Pete Wenzel'" <pete@seebeyond.com>, Joseph Hui <Joseph.Hui@exodus.net> 
                      egrity.com>              cc:       www-ws-arch@w3.org                                                       
                      Sent by:                 Subject:  RE: "Onion model" explained                                              
                      www-ws-arch-reque                                                                                           
                      st@w3.org                                                                                                   
                                                                                                                                  
                                                                                                                                  
                      07/23/2002 02:51                                                                                            
                      PM                                                                                                          
                                                                                                                                  
                                                                                                                                  



I agree with Pete. In my mind you have an AuthZ policy with two distinct
steps, something like this:


1. If (authentication of suitable type does not suceed) ignore message


2. Update the info associated with the party sending the request.


Since you made an implemention choice to do this in program code, you
choose to view these steps as part of the application. However, they could
have just as well been done using an authorization policy infrastructure,
in which case it would be obvious that this constituted authorization.


The WSA glossary defines Authentication as:


To positively verify the identity of a user, device, or other entity in a
computer system, often as a prerequisite to allowing access to resources in
a system


The SAML definition is similar:


To confirm a system entity's asserted principal identity with a
specified, or understood, level of confidence.


Neither says anything about MAKING USE of the identity. I claim that as
soon as you do so, you are doing Authorization or generating Audit trail or
something else.


Hal


> -----Original Message-----
> From: Pete Wenzel [mailto:pete@seebeyond.com]
> Sent: Tuesday, July 23, 2002 2:11 PM
> To: Joseph Hui
> Cc: Hal Lockhart; www-ws-arch@w3.org
> Subject: Re: "Onion model" explained
>
>
> Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Mon, Jul 22,
> 2002 at 08:03:51PM -0700:
> > >From:      Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > [snip]
> > >1. I still maintain that Authentiation is never an end in itself,
> > >   it is a step that collects data to be used in some other
> > >   decision.
> > ...
> > The point I made, as I recall, was to show the fallacy
> > of "authN by itself was *never* enough" [Assertion A].
> > ...
> > here's one heartbeat app with a negative trigger.
> > Every N seconds Alice sends an "I'm-alive" signal to Bob.
> > By sharing a common secret, only Bob knows how to
> > authenticate the signals from Alice.  Bob will invoke
> > Proc A if M heartbeats from Alice are missed.
> > See?  No authZ whatsoever,
>
> But authentication of Alice's signal has a side-effect:  it causes
> Bob to reset his watchdog timer-counter.  Signals that cannot be
> authenticated as coming from Alice should not result in the reset
> behavior.  In other words, we can say that Alice is authorized to
> reset Bob's counter (or, equivalently, that Alice is authorized to
> prevent Bob's execution of Proc A).
>
> > not even Integrity or
> > Encryption (as in the cases of H-MAC or dsig),
> > was involved....
>
> Yes, these have independent uses; clearly sometimes AuthN+AuthZ is
> enough.  However, the heartbeat example doesn't demonstrate that AuthN
> is enough by itself, because there is more taking place than just
> AuthN.
>
> --Pete
> Pete Wenzel <pete@seebeyond.com>
> SeeBeyond
> Standards & Product Strategy
> +1-626-471-6311 (US-Pacific)
>

Received on Tuesday, 23 July 2002 16:05:10 UTC