I was relying on Ben Forta's Advanced Book - Chapter 7 & 8........looking at
the examples on Pages 99 & 109 (Figures (7.10 and 8,9) but I honestly have
not done this myself.
Dave Cahall
Vice President, Professional Services
Digitaris Technologies, Inc.
Office: 972.690.4131 ext 116
Mobil: 214.914.9947
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 21, 2001 12:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Advanced Security quandry...
Hrm... I tend to disagree at this point. Policies are basically the
application of rules against users. Remember that any user associated with
a policy has to be a member of a User Directory associated with the context
to begin with. You can't have a policy applied to a user that isn't a part
of the User Directory(s). On further inspection, I've discovered that the
only difference between development and production is that development has
additional rules and policies that don't exist in the production
environment. As such, development is more comprehensive and granular;
however, for the most part (and for anything that matters at login), the
Rules, Policies, and User Directories are the same. The only difference is
the context name itself.
Besides, we are only applying Advanced Security to UserObjects. For us,
Rules and Policies are only checked when IsAuthorized is invoked. The
failure happens at simple authentication, before IsAuthorized is ever
called. The research I've done indicates that <cfauthenticate> checks to
see if the user and password are valid against *any User Directory*
associated with the specified context, regardless of Rules or Policies.
I've been banging my head against the wall with this for a few hours now.
The only solace I have right now is that I'm getting paid for it... ;-)
Anyone else have any ideas? Ben? :-D
On Tue, 21 August 2001, Dave Cahall wrote:
>
> From what I read, I think that is exactly your problem. Although you are
> using the same UserDirectory, the Policy can define a different set of
users
> for each Context. As I understand it, you need to identify which users
have
> access under each Policy. Therefore, users might be identified in one
> context but not the other. Therefore, when they try to log on, it checks
> the policy to see which users are defined. Meaning (if I understand it)
> that just because they are identified in the UserDirectory, that does not
> mean they will be authenticated. The Rule then determines who (of those
who
> are authenticated) is authorized to perform a task.
>
> I may be way off base here but that is my understanding.
>
> Dave Cahall
> Vice President, Professional Services
> Digitaris Technologies, Inc.
> Office: 972.690.4131 ext 116
> Mobil: 214.914.9947
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 21, 2001 11:57 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Advanced Security quandry...
>
>
> Not a dumb question at all! =-) The only differences between the
contexts
> have to do with Rules and Policies. In the development environment, the
> rules and policies that govern access can be monkeyed with, while in
> production they're pretty set.
>
> I wouldn't think that the Rules or Policies differences are the problem,
> since the thing fails at authentication. Does <cfauthenticate> look at
> anything except the User Directories associated with the referenced
context,
> username and password? And why the heck would it fail with one context
and
> not with the other when the User Directories associated with each are the
> same?
>
> On Tue, 21 August 2001, Dave Cahall wrote:
>
> >
> > This may be a dumb question but what is different in the two contexts?
> >
> > Dave Cahall
> > Vice President, Professional Services
> > Digitaris Technologies, Inc.
> > Office: 972.690.4131 ext 116
> > Mobil: 214.914.9947
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 21, 2001 6:15 AM
> > To: [EMAIL PROTECTED]
> > Subject: Advanced Security quandry...
> >
> >
> > Y'all are gonna love this one! ;-)
> >
> > I've got a client with two applications running on the same CF Server
> (4.5).
> > Let's call the applications DEV and PROD. The user is taking advantage
of
> > CF Advanced Security to handle user authentication against an NT domain
> when
> > the users log into either application. There are separate security
> contexts
> > for each application (CONTEXT_DEV and CONTEXT_PROD). Both contexts use
> the
> > same User Directories to authenticate users against.
> >
> > So here's the dilema. The authentication is working fine for the DEV
> > application. The user logs in using NTLoginID and NTPassword,
> > authenticating against the CONTEXT_DEV context. However, when I use the
> > same code set for the PROD application, the <cfauthenticate> fails every
> > time. The only difference in the code set is the application name and
the
> > security context name. Unfortunately, I can't get any useful
information
> > from the failure. Has anyone else encountered a problem like this?
Does
> > anyone know of a good way to debug this kind of issue?
> >
> > Perplexed,
> >
> > IronFury
> >
> >
> >
> >
-------------------------------------------------------------------------
> > This email server is running an evaluation copy of the MailShield anti-
> > spam software. Please contact your email administrator if you have any
> > questions about this message. MailShield product info:
www.mailshield.com
> >
> > -----------------------------------------------
> > To post, send email to [EMAIL PROTECTED]
> > To subscribe / unsubscribe: http://www.dfwcfug.org
> >
> >
-------------------------------------------------------------------------
> > This email server is running an evaluation copy of the MailShield anti-
> > spam software. Please contact your email administrator if you have any
> > questions about this message. MailShield product info:
www.mailshield.com
> >
> > -----------------------------------------------
> > To post, send email to [EMAIL PROTECTED]
> > To subscribe / unsubscribe: http://www.dfwcfug.org
>
>
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
