>   I have a question or two after reading the Use Cases
> a few times:
>
>   The dependence on a single RegisteredUser value type
> seems, at first glance, as though it might become
> expensive quickly (see Use Case 5b). For most
> purposes, on such a web
> site, there are three types of information:  access
> control (authentication and authorization),
> registration (detailed account information), and
> preferences (start page, favored information, etc).
> The middle one is the least frequently used and often
> the most significant in size. Supposing those
> assertions to be true, it would seem proper to model
> the use cases around lighter-weight objects.

Yes, and your reasons are an excellent explanation of why we will
want to look at that my generic object once we have a general consensus
on the access control stuff.

>
>   Is the System Administrator Agent (or actor if you
> prefer) really necessary? To presume physical access,
> or even shell access, does not necessarily make for an
> effective deployment. If this were for a customer you
> would hardly tell them that they require a database
> administrator to perform certain types of routine
> site-level maintenance. Would it be worthwhile to move
> to a roles-based access control mechanism? Say with an
> expression such as "SiteAdmin(1) > Moderator(*) > User
> (*)>
> Guest(*)"? Then we would simply add the cases necessary
> for the SiteAdmin to change the access of a Moderator,
> but a Moderator would be unable to do the opposite.

I was trying to keep it simple.  I made a rough guess that it
would take about three System Administrator acts per year to keep the
system running, and for that little effort, in rev one, direct
database manipulation was a reasonable tradeoff.  The issue of
guest level access is an interesting point.  What are the use cases
where
we would need that?

Also, I completely left out the uses where other Backend services would
need to verify that their User had a required privilege.

>
>   In Use Case 1d, should the Backend be transmitting
> the message? This is really not a question of where
> the event should take place; the appserver is clearly
> the correct spot. I think it calls us to consider the
> grouping of database engine and appserver into a
> single conceptual tier called "Backend". While our current
> hardware constraints may make that necessary, and
> there is nothing intrinsicly disordered about such a
> configuration, it might be useful to still describe
> them separately in the Use Cases.

You're reading too much into the Backend agent.  How it gets
designed is up to us.  At the level we are modeling now, with
User, Middleware, and System Administrator, the Backend is just one
piece, but when we design it, we can break it up however we like.

>
>   Is Use Case 2 a realistic situation? In what
> context would a login lead to a reqistration request?
> As a web user, I would certainly find that quite
> irritating.

You've got me stumped here.  I think you've misunderstood the
use case.  All I'm saying is that the Middleware can read from
the value object all of the values that it needs.  If it doesn't
have a value object, it needs to get one.  Ordinarily the Middleware
would cache the value object in the Session object, so once the user
logs
in, the Middleware would remember who he/she is.


>
>   The second paragraph of the "Design note" leaves me
> thoughtful. While I understand the principle at use
> here, the implementation does not appear to lead
> obviously to the described result. In a situation
> where there is stateless communication between the
> Middleware and Backend, it is clearly necessary that
> the User's credentials are part of each request,
> otherwise there would be no point in separating User
> from Administrator. By way of implication, however,
> this note describes some kind of security auditability
> increase derived therefrom, and more troubling still
> and easy correction of problems. Unfortunately, this
> does not appear to my untrained eyes to be an accurate
> assessment.

Okay.  The most common problem that I have seen is that
people design their security so that there is a login step.
They build the login step into their Middleware design.  But
once the user crosses that threshold, the Middleware can simply
forget who they are (they're here, they must have cross the threshold).
You and I agree that security must be at the Backend.  If that is
done, then there is less chance that an incorrect design or code in the
Middleware will lead to unauthorized or unauthenticated access.

>The communication between the browser and
> the Middleware is completely not secured, and is
> therefore quite easily hijacked. When you can hijack a
> session, there is no serious Middleware security
> because the Middleware can be made to "lie".
>   Meanwhile the communication between the Middleware
> and Backend is similar not secure, and also quite
> easily hijacked. In that context, it makes no
> difference if the Middleware is even secure because a
> third party can easily implement a man-in-the-middle
> attack against the installation.

The use cases did not address the issues of security attacks
by the User or third parties.  A use case can be added for these
issues.

>   While the "Design note" may be a best practice, and
> I agree with you wholeheartedly that it is, it does
> not impart the benefits, to my understanding, as
> described. Perhaps I am terribly mislead or ignorant.
> In either case, it would be quite happy to be
> disabused of this notion.
>
> christian
>

Christian,

   Why not take the use cases that I submitted, your comments,
my comments and rework them?  In the end, we want simplicity.
It's one of the hardest attributes of software to achieve; it
has to be obtained early on, and it's always worth the effort.

   By the time we've passed this around the entire group once,
we should just about have it.