[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-users] RE: PerClauses
|
Ramnivas, thank you for your reply :)
Although my domain-tier will be implemented in ( largely open-source ) java,
it is a requirement that the web presentation layer be IIS/ASP. The
implementation of presentation layers for other formats ( phone, db2db ) are
likely too to require a Microsoft skin. Consequently, there is a runtime
translation layer between java/COM environments and thread identity is not
guaranteed between the two ( and in any case there are multiple invocations
per user-thread ). So...
If we specify from the beginning that client-facing objects are created new
per user-thread (request), then their object-identity stands proxy for the
thread's identity.
We can further specify a contractual arrangment (*grimace*) that callers of
the domain tier, be they scripts or languages of whatever type, call only
Authorizables and call setSubject(Subject) before they call anything else on
that Authorizable on that same thread. The Subject they have already gained
from the LoginContext and stored in whatever passes for their sessioning
system.
The aspect can then gain the subject from the object-identity of the
pointcut context.
package com.abnamrocraigs.auth;
public interface Authorizable{
public abstract void setSubject(Subject s);
Subject abstract getSubject();
public boolean equals(Object other){
// return (this == other); required condition
}
}
public abstract aspect AbstractAuthAspect{
abstract pointcut authOperations(Authorizable a);
around(Authorizable a): authOperations(){
Subject subject = a.getSubject();
Subject.doAsPrivileged(subject, etc...
}
}
Howzat?
craig collings
Message: 2
Date: Tue, 19 Aug 2003 23:50:18 -0700 (PDT)
From: Ramnivas Laddad <ramnivas@xxxxxxxxx>
Subject: Re: [aspectj-users] Re: PerClauses
To: aspectj-users@xxxxxxxxxxx
Reply-To: aspectj-users@xxxxxxxxxxx
Craig,
If you use the percflow(login()) association, your advice to
logout() and authOperations() won't execute at all due to
implicit limiting of the join points (see AJIA page
132-134). I am asumming that you meant to put all the
mentioned pointcuts and advice in AbstractAuthAspect (and
associate it with percflow(login()).
So the question remains is where do you store your
authenticated subjects and how you fetch the right subject
when a an operation matching the authOperation() pointcut
is executed? Session would be a good place as Ron suggests,
but your design does not seem to favor it. I think you still
need to find some sort of "session-like" object.
A few questions that may lead to an answer:
1. Would the sequence of operation be login-op1-op2-...-logout,
all happening in a single thread? If so you can either:
A. Associate the subject with the caller thread
of the login() method.
(use of ThreadLocal would be a good choice).
B. Use percflow() for the join point that surrounds these
sequence of calls. For example, if you have
perform(..) {
login()
op1()
op2() (these may in turn call other operations
directly/indirectly needing authorization
check)
logout()
}
you can associate the aspect with
perfclow(exceution(* perform(..)). Then, you can keep
your subject as an instance variable of the aspect
(no need to use a map).
2. Is subject related to the client machine somehow? And if so
would there be more than one subject concurrently accessing
from a machine?
-Ramnivas
--- Craig Collings <Craig.Collings@xxxxxxxxxxxxxxxxx> wrote:
> Thank you Ron, for such a thoughtful and authoritative reply.
>
> However, I would really like to avoid the use of sessions altogether.
>
> It is part of the design brief that the information server be
> co-operable
> with (and therefore agnostic of) any forseeable delivery protocols.
> From
> which follow these conditions with regard to sessions:
>
> 1) Only stateless protocols will require sessions,
> 2) Auth sessions on the information server will be a subset of
> sessions
> generally,
> 3) There will be a one-to-one correspondance between Auth sessions
> and JAAS
> Subjects,
> 4) Sessions will have protocol-specific interfaces not wholly
> definable at
> this time,
> 5) The sessioning mechanisms will probably be running in a different
> process
> and will, in any case, be a "black box" as far as I am concerned.
>
> If we did go with sessions...
>
> What we could do, at the adoption of a new session type, is use
> aspects to
> ensure its conformance to an interface which we can fully specify
> right now
> :)
>
> For those platforms requiring sessions, the natural place to pass
> them into
> the auth framework would seem to be the LoginModule CallbackHandler
> which
> would associate a sessionId with the Subject. This may mean a subtype
> of
> CallbackHandler for each protocol adopted - such is life.
>
>
> But I would really like to avoid the use of sessions at all....
> So what I'm thinking of at the moment is:
>
> percflow(login)
>
> where
>
> pointcut login(LoginContext c): target (c) && call(boolean
> LoginContext.login());
> pointcut logout(LoginContext c): target (c) && call(boolean
> LoginContext.logout());
> abstract pointcut authOperations();
>
>
> The task now is to keep this aspect alive until logout so that there
> exists
> precisely one aspect instance per current login:
> we will keep the aspect alive by using it as a Map key.
> So within this AbstractAuthAspect:
>
> protected static Map liveSubjects = new HashMap();
>
>
> after(LoginContext c) returning: login{
> Subject subject = c.getSubject();
> synchronized(AbstractAuthAspect.liveSubjects){
> AbstractAuthAspect.liveSubjects.put(this, subject);
> }
> }
>
> after(): logout{
> synchronized(AbstractAuthAspect.liveSubjects){
> Subject subject =
> (Subject)AbstractAuthAspect.liveSubjects.remove(this);
> subject = null;
> }
> }
>
> around(): authOperations{
> Subject subject =
> (Subject)AbstractAuthAspect.liveSubjects.get(this);
> // Subject.doAsPrivileged(subject etc....
> }
>
> This aspect-subject association differs logically from a simple
> member
> Subject only by using the Map to keep the aspect alive.
> It is the associated Subject (one per login) that will be tested for
> permissions.
>
> Ok so far, but what I now need to know is:
> which live aspect will advise around authOperations and after logout?
> All of the live aspects?? (clearly no good)
> or just the aspect created for login? (which would be very good)
>
> In other words, by what mechanism is an advice notified that its
> associated
> pointcut has been reached?
> And how does this differ under different aspect instantiation
> schemes?
>
>
> I hope these questions aren't considered excessively lazy, its just
> that
> documentation is never quite sufficient :)
>
> craig collings
> architect
> abnamrocraigs.com
>
>
#####################################################################################
Notice of Confidential information
The information contained in this electronic mail is CONFIDENTIAL INFORMATION and may
be LEGALLY PRIVILEGED, intended only for the individual or entity named above. If you
are not the intended recipient, you are hereby notified that the use, dissemination,
distribution, or copying of this document is strictly prohibited. If you have received
this electronic message in error, please immediately notify us by return or telephone
call collect to 07 577 6049) and destroy the original message. Thank you, ABN AMRO Craigs Limited.
This e-mail message has been scanned and cleared by MailMarshal www.marshalsoftware.com
#####################################################################################
