>
> Most of the systems, for example, call the database then create some
> type of
> “user” object then store that in the session scope. That’s fine, but
> problems occur if an admin changes the person’s permissions (since
> they
> won’t take effect until the next log in) or the user ends up with
> multiple
> sessions. It just always seemed somehow “flimsy” to me (even tho’
> I’ve done
> it in the past myself).
A rather brute-force way of handling permission changes is to force
that (or all) user to re-login after a permission change, A bit
inconvenient, but probably acceptable because you likely wouldn't do
it often
> The primary goal for me was to design a system that required very
> little
> knowledge of the application it was protecting. The system I’ve
> described
> (but remember I haven’t built it yet – so this is all conjecture)
> will work
> just fine if the application doesn’t enabled the session scope (in
> fact if
> you instantiate it in the server scope you don’t even need the
> application
> scope).
I like that!
> The outside application defines the “touch points” and keys used to
> get at
> the information. I’m actually quite pleased with that fact: it was an
> important turning point for me not to consider how to get things
> “into the
> session” and using the session as a cache point.
So, conceptually, you are securing the server, thru that the
application, and thru that the user, and thru that each user request.
And, you can have as much (or as little) security at each level as you
want,
> The system is complex, but caches its information very aggressively
> so (I
> hope!) it should still be quite fast. The caching adds complexity
> but also
> enables us to deal with multiple entities working on the same data
> very
> gracefully. When I, as an admin, revoke or add permissions on your
> account
> you’ll see the change on the very next request.
With your design, will you have a graceful way of disabling/re-enabling
an applications permissions?
This is useful for periodic backups and upgrades.
> Once I get the damn thing done it should be a nice, clichéd “black
> box” –
> you won’t have to know how it works inside to use it. As I said the
> system
> itself won’t have any interface at all (although when/if I distribute
> it
> I’ll include a sample interface) so it’ll be applicable to pretty
> much any
> CF application.
In your initial post you said (early on):
"The security system would not secure itself. Perhaps this is
wrong, but I didn't want to make it that complicated"
and (at the end)
"Although I'm truly pleased with the end-user side of things I'm not so
sure yet about the admin side of things..."
Isn't the logical resolution that:
1) To the "Security" system the Admin is just another, albeit special,
application
2) The "Security" system must be robust enough to allow enough function
to the Admin application, that it can enable/disable the "Security"
system.
3) When disabled, the "Security" of the server (and all that flows from
it) could be: Lockdown; or open access;
Also, I wonder if this (security system) might be fairly easy to
prototype. Consider that most applications have an Application.cfm
file.
You could have each request invoke the main security module main.
this would, initially just gather/log/cache info and return.
Another app could real-time monitor the log/cache with some
sort/display/zoom options. You will want to have this app anyway as a
security monitor control panel. If you write it early, it will help
you design and implement the rest of the system
You could implement the other functions (cfcs) as skeletons
(gather/log/cache & return) and add the associated "touch points" to
selected applications.
This way you can simulate/observe the security system without affecting
the applications.
Jim, thanks for the additional explanation -- I think that I understand
what "it" does & why I need it.
Keep us posted.
Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
