>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
That does work... but we can do better! ;^)
Also, at least in the other canned system's I've seen out there this is
really (surprisingly) difficult.
In these systems the security information is copied to the session (and
there is normally no way for an application to access all of its attendant
sessions). All the security system checks is the roles/groups information
stored in the session against the allowable roles/groups stored in the
template (or, even worse, just checks a simple "logged in" Boolean in the
session scope itself).
So without restarting the application there's no way to force new logins
because after authenticating these systems NEVER check with the security
system again. That's a bad thing, I think.
>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,
Sorta, kinda?
In the simplest case the application.cfm (or some other single point of
entry) would just check to see if the user was authenticated (not caring
about the roles) like this:
<cfif DP_Security.isAuthenticated(SessionKey)>
The session is logged in
<cfelse>
The session is not logged in
</cfif>
The actually entitlement system is pretty simplistic right now: you define a
group (say "administrator") and add UserKeys to it (using an admin system
that hasn't been defined yet). After authentication the check entitlement
code would be (something like):
DP_Security.isEntitled(SessionKey, "Adminstrator").
However you could get very fine grained if you like. You could define
Groups that cover functionality just as easily as location. For example you
might define a group called "Admin_DeleteUser". Then, in your admin system
you could do something like this:
<cfif DP_Security.isEntitled(SessionKey, "Admin_DeleteUser")>
Present the control to delete a user.
</cfif>
This is what I meant by "the security system doesn't protect itself" -
instead you protect the security by defining (in as detailed a fashion as
you like) entitlement groups and building your admin UI around them.
I've enough on my plate now, but in the future I'd like to expand this to
include more advanced entitlements: nested groups of entitlements (allowing
you to say that "DeleteUser", "AddUser" and "EditUser" are all part of the
"Admin" group), linked entitlements (so you could say "You must be part of
BOTH these groups to do this, not just one or the other"), and other things.
I could also see Applications that use this system ship scripts for updating
existing instances of the system themselves. For example if I were to ship
a Forums application using this system I could also ship a small script that
added some Forum specific groups to an already in-place system. That way
you could easily set up the application by itself or integrate it easily
with an existing application.
Lastly I also plan (since this is something I've built for 4.5-based systems
and really like) to include the ability to passed authentications from one
system to another and define trust relationships across them. This will
probably be done via web services, but the idea is that I could define a
relationship on FirstNight.org that says "Anybody from DepressedPress.com is
alright with me!" and allow them in.
In that case there would be a special link on the sites that passed the
authentication information, but the system would (almost have to) allow for
full web service access to authentication: meaning you could set up a single
authentication provider for multiple websites (although I can't guarantee
performance!)
Even with as much as I've described there's loads of room for improvement.
>With your design, will you have a graceful way of disabling/re-enabling
>an applications permissions?
>
>This is useful for periodic backups and upgrades.
Well, I hadn’t thought about it... but I suppose I should.
As it stands the Credential has an "isActive" property than can be set to
true to temporarily disable access to a particular user without deleting
them.
Now that you mention it however I suppose an Entitlement (Group) should also
have a property like that, uh? Then you could "turn off" a group
temporarily.
I'm not sure how I'd implement it tho'... the simplest method would be to
just return "false" when the entitlement was asked for. That would work,
but how would the interface know that the user had access but that the group
was disabled versus the user just not having access.
I suppose that's just another thing I could leave to the interface...
Good idea tho, even if I'm not sure how to best do it.
>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
Exactly true. Although it's not really even "special" to the system - it's
just another resource you've defined. I guess another way to word it is
that everything in the system is protected just as well as the admin.
And I think that this will work out. Some people may want to limit all
group functionality (for example) to admins while other applications may
not. Consider an application that allowed people to create online
photo-albums. You could (I think) leverage the system to allow any user to
create a "group" to represent the album then pick (or add) some people to
see it and others to edit it.
People might be allowed to delete themselves from a system.
I can see a lot of cases where somebody might want functionality that I
consider "admin only" to be given to anybody.
Also keep in mind that there's nothing that says you must have only one of
these systems active at a time: you can have a single application that
creates several distinct user communities by instantiating several
DP_Security systems.
>2) The "Security" system must be robust enough to allow enough function
>to the Admin application, that it can enable/disable the "Security"
>system.
True again - although I may not offer all that much control in the first
release. But I would want to see some pretty advanced functions in there
eventually. For example it might be nice to place limits on the number of
people allowed in the system as a whole or allowed in from a certain group.
You could then say, for the sake of simplicity, that you have three admins
defined, but only one of them is allowed to access admin functionality at a
time.
You could also say "only 50 people at a time are allowed in this
application" to manage performance.
>3) When disabled, the "Security" of the server (and all that flows from
>it) could be: Lockdown; or open access;
"Lockdown" would depend on the application: since it's up to you to place
the entitlement/check points you could leave holes, but in general that's
possible.
>Also, I wonder if this (security system) might be fairly easy to
>prototype. Consider that most applications have an Application.cfm
>file.
Since I'm building it now I'll let you know! ;^)
>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
Good idea. I'll have decide how/where/what on that one, but it does sound
useful.
>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.
I will. I hope to have the skeleton done this weekend... then comes the fun
of testing/debugging. ;^)
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
