again. If my user object says I'm logged in, then I'll be able to identify
myself as that user in the second window, and be logged in, without actually
using a password. Same goes for Joe Hacker over in CountryXYZ. As soon as
I log on, and he can identify himself as me, he's acting as me. So clearly
we don't want to log users onto the system. Rather, we want to log browser
windows onto the system, on behalf of a user.
So I log in with my first window, and then try the second. I identify
myself as me, but the system says "yeah, prove it. You might have logged on
over there, but not here." Much better, and poor Joe Hacker is outta luck.
Moral of the story? Don't log users in, log sessions in, and associate each
session with both a user, and an identifiable single point of access.
Usually done with a session instance of a user CFC and a cookie. To get to
the real answer you're looking for, you don't want to have anything about
authentication in your user component, you need a separate object (or
perhaps even a boolean and a numeric field in the session scope).
Now, on to authorization. I'm logged in, and want to perform the "Edit
User" task on the system. Who are you going to ask if I've got permission?
Certainly not me, I hope, because I'll obviously say "yes". I probably know
whether I can do the action or not, but I'm a stinkin' liar. Rather, you
should ask the security system, if user 'barneyb' has permission to do the
"Edit Users" task. The security system is objective, and tied very closely
to the database, unlike myself, who in addition to being a liar, could well
have data that's an hour or three old, because I was given my specs when I
logged in.
If you have a dedicated security system, you get the added benefit of being
able to cache data fairly aggressively. If all DB queries and updates go
through you, then you can rest assured keeping some data in memory for
faster access is OK, because nothing is going to manipulate the database
without you knowing. Heavy caching is of particular benefit to security
info, because it's often stored in a very distributed form, across many
tables, and is needed on every request, almost always multiple times per
request.
To sum up, authentication is independent of users, because users can have
zero to N sessions, and each session needs to be independent. Authorization
is not a user task, it's a system task. Users can probably tell you about
their various authorization levels, but they're not the authority.
I don't use a separate authorization component (at least not that the
controller can see), I put the methods directly into the service component
that is used for managing the credentials. Nice consolidated package, and
since it's that way, I can cache to my hearts content.
It's late, I'm tired; sorry for the storytelling and longwindedness.
Cheers,
barneyb
> -----Original Message-----
> From: Jim Davis [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 28, 2004 8:41 PM
> To: CF-Talk
> Subject: Security with CFCs
>
> I know, old topic, but I'm currently converting my old CF
> 4.5/5.0 framework
> (which actually began with v3.x and has been updated ever since - so a
> complete overhaul is long overdue) to a object-leaning
> CFC-based setup.
>
> Note I say "object leaning" because I'm not trying to
> recreate any major
> pattern or do everything in OO - I'm trying to keep the best
> aspects of
> procedural code, but move the foundational elements into
> CFCs. So far it's
> been going great - I'm extremely pleased with what I've got so far.
>
> Basically there are now a bunch of CFCs: three of them mirror
> CF's view of
> the world so I've got a DP_Application.cfc (application
> settings, DSNs,
> etc), DP_Session.cfc (Session information) and a DP_Request.cfc
> (page/request specific stuff like current paths and
> settings). I've also
> done CFCs (and DAO components) for Clickstreaming, Agent (browser)
> Information and Navigation.
>
> Like I said - so far I'm very pleased.
>
> But now I'm trying to convert my security system over. The
> data-side of the
> system is as simple as can be. The usual three tables:
> Users, Groups and
> Users2Groups. In the users table I've got a number of fields
> for use with
> the security system itself (password hash, userID, login
> dates, number of
> logins, etc) and a very large number of fields to cover
> personal information
> (name, various addresses and phone numbers, IM IDs, email
> preferences, etc).
>
> As you can guess each page can be restricted to certain
> groups, users can
> belong to multiple groups, etc.
>
> Anyway - what I'm trying to do now is determine how to do
> convert security.
> Anybody done this and want to share?
>
> My current thinking is that there are many functions specific
> to application
> security - things like authenticating,
> adding/editing/removing groups, etc.
> I've started putting them into a "DP_Security.cfc" which will
> be loaded as a
> property of the DP_Application.cfc (I could have put them
> inside it, but it
> was already getting a little long).
>
> Then there are a bunch of things that are user-level: putting
> a user into a
> group, updating passwords, getting personal information, etc. So I've
> created a "DP_User.cfc" that would contain all the
> information about the
> user and be cached as a property of DP_Session.cfc (in the
> session scope).
>
> However I'm hung up on the particulars.
>
> If a populated user's component means you've logged in, what
> should indicate
> no log in? An empty component? A component that hasn't been
> inited or no
> users component at all?
>
> Should the security system, when authenticating, return the
> user object or
> just the UserKey and let the user object populate itself?
>
> In the end I want to easily say "isLoggedIn()" or "isAdmin()" or
> "isEntitled()" - preferably from the session-based user
> component. But at
> the same time it seems odd to me that a single set of DB
> tables has multiple
> components operating on them.
>
> As I said I'm converting this code over so it all works (but
> right now is
> decentralized in several custom tags, the login templates,
> etc) so I know
> how to deal with data and I've got the actual security
> concepts down pat -
> it's the OO aspects that have me stumped.
>
> Any words of wisdom?
>
> Thanks,
>
> Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
