Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates
 209.85.200.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        b=mgfQcLzl9SPkshQHgSsdmDLKiZgPxh9UT0mxBhDoyaEZm25f8g4ghRqZCp5Iws7JRl
         YmNeb1fsRtFJSPhQyT8qRsfr0MMPQyXuS8kPWSwqJlBbLmf5Wh25WBnoT5F0+8aF/WKH
         2tvpwoHndRfjwuMpr4Mbal7wDTlhrIyhmIrMY=
MIME-Version: 1.0
Sender: akarasulu@gmail.com
Date: Fri, 30 Jan 2009 16:07:56 -0500
Message-ID: <a32f6b020901301307p727d9dbch2193ee139f9e14d3@mail.gmail.com>
Subject: [ApacheDS] [RFC 4370] Why we should implement the "Proxied
	Authorization Control"
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: multipart/alternative; boundary=001636e0a8845b6c250461b99907

--001636e0a8845b6c250461b99907
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi folks,

Lately we've been thinking about disaster recovery and leveraging the change
log to recover from partition corruption. We've also mixed into the fray the
idea of building up a replica after a nascent server is added to a cluster.
We also spoke about applying the changes in the CL of one server to bring a
fresh server to some previous state.

In all these cases, and a couple more below,

   - exporting then reimporting
   - connection pooling


there is a distinct need to preserve the identity information associated
with the creatorsName and the modifiersName. In the above examples, the
server internally must apply changes in the change log as the identity of
the creator and modifier.  In most cases timestamps should also be
preserved. Internally this is easy to do with ApacheDS' API. However it is
not so easy when changes are coming from outside of the server.  For example
when bringing a new replica into a cluster and loading it with entries it's
very hard to preserve the values of these operational attributes.

Currest State
-------------------

Some leg work was done to be able to implement a "RunAs" capability in
ApacheDS. An autorizedPrincipal property and effectivePrincipal was added to
all operation contexts [0] via a base class.  The authenticatedPrincipal and
yet another effectivePrincipal is accessible via the CoreSession [1]. The
DefaultAuthorizationInterceptor [2] was indirectly modified via it's base
class, BaseInterceptor [3], to leverage the effectivePrincipal.

There needs to be some clarification here as to what all this is about. A
session must have an authenticated principal and my optionally have an
authorized principal. The authenticated principal is the principal whose
credentials were provided to bind after establishing the session.  The
authorized principal is another identity associated with the session rather
than with an individual request. There are, I believe, SASL mechanisms that
would set this authorized principal. When this is the case, operations
should be performed as the authorized user.  Hence the
getEffectivePrincipal() method on the CoreSession checks if an authorized
principal exists and returns that or in it's absence returns the
authenticated principal.

AbstractOperationContext [0], also contains an authorized principal and has
access to the CoreSession. These operation contexts represent requests being
processed. Eventually with the proxied authorization control implemented,
this authorized principal will be populated when the control is used to
issue requests. The effectivePrincipal() method on OperationContexts will
return the authorized principal when it is set at the request level. If it
has not been set then the session.getEffectivePrincipal() value is returned
by a context.

Need for Controls
-------------------------

There is really very little work that remains to implement this great
control. It's great because it facilitates a single connection to issue
requests as another user.  This is obviously a huge plus when dealing with
connection pooling. But more importantly it's a plus when dealing with
bringing a replica online and up to speed with the contents of it's peers in
a cluster.  It will allow the a user with the proper authorization power to
write entries to the DIT with the identity that was originally used to
perform the operation hence preserving the creatorsName and the
modifiersName.  This is important to do since these attributes can impact
auditing, and access controls [4].

Likewise we should preserve modifyTimestamp and the createTimestamp
operational attribute.  There is no specification for doing this as far as I
know but a control which carries with it the timestamps to use can be very
useful here.  Perhaps this is also something we can explore.

Now all these operationalAttributes have the directoryOperation USAGE and
not distributedOperation or dSAOperation. This is somewhat confusing.  If
the dSAOperation were used then that would tell us that these values can be
different for each server.  If distributedOperation was used then it's
something I would imagine would need to be the same across replicas.
Although confusing I think these operational attributes must line up across
replicas in the cluster otherwise you have divergence.

Stored Procedures and Triggers
----------------------------------------------

When we get the SP and trigger story right, the RunAs code will come in very
handy. For example, an administrator installs a trigger to fire a SP
whenever an entry is deleted in some region of the DIT. The SP updates
groups by removing references to the deleted entry.  The groups are
protected from ACI to prevent anyone but the administrator to make changes.
When a normal user raises the trigger, that trigger will need to execute the
SP with the authorization rights of the administrator.  The procedure will
then execute as the administrator.

Summary
--------------

This control as well as another to support the preservation of timestamps is
needed to do several things correctly.  Thankfully we already have some
foundation to build on so their implementation would not be that involved.


Thanks,
Alex

-------------------
[0] -
http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/interceptor/context/AbstractOperationContext.java?revision=702434&view=markup
[1] -
http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/CoreSession.java?revision=725712&view=markup
[2] -
http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/authz/DefaultAuthorizationInterceptor.java?view=log
[3] -
http://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/interceptor/BaseInterceptor.java?revision=702434&view=markup
[4] - Nothing in ApacheDS exists yet to leverage the creatorsName or the
modifiersName to conduct access decisions

--001636e0a8845b6c250461b99907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi folks,<br><br>Lately we&#39;ve been thinking about disaster recovery and=
 leveraging the change log to recover from partition corruption. We&#39;ve =
also mixed into the fray the idea of building up a replica after a nascent =
server is added to a cluster.&nbsp; We also spoke about applying the change=
s in the CL of one server to bring a fresh server to some previous state.<b=
r>
<br>In all these cases, and a couple more below, <br>&nbsp;&nbsp;&nbsp; <br=
>
&nbsp;&nbsp; - exporting then reimporting<br>
&nbsp;&nbsp; - connection pooling<br>
<br><br>there is a distinct need to preserve the identity information assoc=
iated with the creatorsName and the modifiersName. In the above examples, t=
he server internally must apply changes in the change log as the identity o=
f the creator and modifier.&nbsp; In most cases timestamps should also be p=
reserved. Internally this is easy to do with ApacheDS&#39; API. However it =
is not so easy when changes are coming from outside of the server.&nbsp; Fo=
r example when bringing a new replica into a cluster and loading it with en=
tries it&#39;s very hard to preserve the values of these operational attrib=
utes.<br>
<br>Currest State<br>-------------------<br><br>Some leg work was done to b=
e able to implement a &quot;RunAs&quot; capability in ApacheDS. An autorize=
dPrincipal property and effectivePrincipal was added to all operation conte=
xts [0] via a base class.&nbsp; The authenticatedPrincipal and yet another =
effectivePrincipal is accessible via the CoreSession [1]. The DefaultAuthor=
izationInterceptor [2] was indirectly modified via it&#39;s base class, Bas=
eInterceptor [3], to leverage the effectivePrincipal.<br>
<br>There needs to be some clarification here as to what all this is about.=
 A session must have an authenticated principal and my optionally have an a=
uthorized principal. The authenticated principal is the principal whose cre=
dentials were provided to bind after establishing the session.&nbsp; The au=
thorized principal is another identity associated with the session rather t=
han with an individual request. There are, I believe, SASL mechanisms that =
would set this authorized principal. When this is the case, operations shou=
ld be performed as the authorized user.&nbsp; Hence the getEffectivePrincip=
al() method on the CoreSession checks if an authorized principal exists and=
 returns that or in it&#39;s absence returns the authenticated principal.<b=
r>
<br>AbstractOperationContext [0], also contains an authorized principal and=
 has access to the CoreSession. These operation contexts represent requests=
 being processed. Eventually with the proxied authorization control impleme=
nted, this authorized principal will be populated when the control is used =
to issue requests. The effectivePrincipal() method on OperationContexts wil=
l return the authorized principal when it is set at the request level. If i=
t has not been set then the session.getEffectivePrincipal() value is return=
ed by a context.<br>
<br>Need for Controls<br>-------------------------<br><br>There is really v=
ery little work that remains to implement this great control. It&#39;s grea=
t because it facilitates a single connection to issue requests as another u=
ser.&nbsp; This is obviously a huge plus when dealing with connection pooli=
ng. But more importantly it&#39;s a plus when dealing with bringing a repli=
ca online and up to speed with the contents of it&#39;s peers in a cluster.=
&nbsp; It will allow the a user with the proper authorization power to writ=
e entries to the DIT with the identity that was originally used to perform =
the operation hence preserving the creatorsName and the modifiersName.&nbsp=
; This is important to do since these attributes can impact auditing, and a=
ccess controls [4].<br>
<br>Likewise we should preserve modifyTimestamp and the createTimestamp ope=
rational attribute.&nbsp; There is no specification for doing this as far a=
s I know but a control which carries with it the timestamps to use can be v=
ery useful here.&nbsp; Perhaps this is also something we can explore.<br>
<br>Now all these operationalAttributes have the directoryOperation USAGE a=
nd not distributedOperation or dSAOperation. This is somewhat confusing.&nb=
sp; If the dSAOperation were used then that would tell us that these values=
 can be different for each server.&nbsp; If distributedOperation was used t=
hen it&#39;s something I would imagine would need to be the same across rep=
licas.&nbsp; Although confusing I think these operational attributes must l=
ine up across replicas in the cluster otherwise you have divergence.<br>
<br>Stored Procedures and Triggers<br>-------------------------------------=
---------<br><br>When we get the SP and trigger story right, the RunAs code=
 will come in very handy. For example, an administrator installs a trigger =
to fire a SP whenever an entry is deleted in some region of the DIT. The SP=
 updates groups by removing references to the deleted entry.&nbsp; The grou=
ps are protected from ACI to prevent anyone but the administrator to make c=
hanges.&nbsp; When a normal user raises the trigger, that trigger will need=
 to execute the SP with the authorization rights of the administrator.&nbsp=
; The procedure will then execute as the administrator.<br>
<br>Summary<br>--------------<br><br>This control as well as another to sup=
port the preservation of timestamps is needed to do several things correctl=
y.&nbsp; Thankfully we already have some foundation to build on so their im=
plementation would not be that involved.<br>
<br><br>Thanks,<br>Alex<br><br>-------------------<br>[0] - <a href=3D"http=
://svn.apache.org/viewvc/directory/apacheds/trunk/core/src/main/java/org/ap=
ache/directory/server/core/interceptor/context/AbstractOperationContext.jav=
a?revision=3D702434&amp;view=3Dmarkup">http://svn.apache.org/viewvc/directo=
ry/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/inter=
ceptor/context/AbstractOperationContext.java?revision=3D702434&amp;view=3Dm=
arkup</a><br>
[1] - <a href=3D"http://svn.apache.org/viewvc/directory/apacheds/trunk/core=
/src/main/java/org/apache/directory/server/core/CoreSession.java?revision=
=3D725712&amp;view=3Dmarkup">http://svn.apache.org/viewvc/directory/apached=
s/trunk/core/src/main/java/org/apache/directory/server/core/CoreSession.jav=
a?revision=3D725712&amp;view=3Dmarkup</a><br>
[2] - <a href=3D"http://svn.apache.org/viewvc/directory/apacheds/trunk/core=
/src/main/java/org/apache/directory/server/core/authz/DefaultAuthorizationI=
nterceptor.java?view=3Dlog">http://svn.apache.org/viewvc/directory/apacheds=
/trunk/core/src/main/java/org/apache/directory/server/core/authz/DefaultAut=
horizationInterceptor.java?view=3Dlog</a><br>
[3] - <a href=3D"http://svn.apache.org/viewvc/directory/apacheds/trunk/core=
/src/main/java/org/apache/directory/server/core/interceptor/BaseInterceptor=
.java?revision=3D702434&amp;view=3Dmarkup">http://svn.apache.org/viewvc/dir=
ectory/apacheds/trunk/core/src/main/java/org/apache/directory/server/core/i=
nterceptor/BaseInterceptor.java?revision=3D702434&amp;view=3Dmarkup</a><br>
[4] - Nothing in ApacheDS exists yet to leverage the creatorsName or the mo=
difiersName to conduct access decisions<br>

--001636e0a8845b6c250461b99907--