|
Home > Archive > IIS Server Security > February 2007 > chabge authentication protocol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
chabge authentication protocol
|
|
| dareag 2007-02-23, 7:21 am |
| I have an ISAPI dll that uses basic authentication, validating users in a
local database. I want to fist try and authenticate users using windows
authentication; if this fails, (ie they do not have a windows account), I
want to use the previous method of authenticating.
How do I do this? Can I try NTLM and then revert to Basic. I tried using
'Integrated Windows Authentication', but I couldn't see how to force Basic
afterwards. I also need the dll to run as the anonymous user, so that the
user has the correct directory permissions.
I guess the alternative is to let the user determine which account to
authenticate against. If I did this would it still be anonymouse access?
--
regards Dave
| |
| Kirit Sælensminde 2007-02-24, 7:21 am |
| On Feb 23, 7:58 pm, dareag <dar...@discussions.microsoft.com> wrote:
> I have an ISAPI dll that uses basic authentication, validating users in a
> local database. I want to fist try and authenticate users using windows
> authentication; if this fails, (ie they do not have a windows account), I
> want to use the previous method of authenticating.
>
> How do I do this? Can I try NTLM and then revert to Basic. I tried using
> 'Integrated Windows Authentication', but I couldn't see how to force Basic
> afterwards. I also need the dll to run as the anonymous user, so that the
> user has the correct directory permissions.
Our FOST.3 framework does this. Every user has credentials information
stored in the database. If the user is registered as an Active
Directory/local user then the framework returns its own 401 response
triggering IIS to check the credentials against the users using basic
authentication/NTLM or whatever other authentication protocols are set
up for IIS.
If the user is registered such that the password is in the database
then this password is checked by the framework. For active directory/
local users IIS informs you of the authenticated user in the server
variables.
In both cases a cookie set on the browser session (database users
could have a longer cookie) to tell the framework how the user is
authenticating.
There are a number of details that need to be right to make it secure,
but that's the gist of it.
>
> I guess the alternative is to let the user determine which account to
> authenticate against. If I did this would it still be anonymouse access?
We also allow anonymous access to the site. If you're going to be
using the normal log in process seen on most web sites then this will
look to IIS like anonymous access and you have to check the user
settings on each page request.
It should also be possible to write an authentication plug-in to IIS,
but it's not something we've really looked at. I suspect it'll be a
lot more complex than the way we've done it.
K
| |
| DaveMo 2007-02-25, 7:20 am |
| On Feb 24, 12:28 am, "Kirit S=E6lensminde"
<kirit.saelensmi...@gmail.com> wrote:
> On Feb 23, 7:58 pm, dareag <dar...@discussions.microsoft.com> wrote:
>
a[vbcol=seagreen]
I[vbcol=seagreen]
>
sic[vbcol=seagreen]
he[vbcol=seagreen]
>
> Our FOST.3 framework does this. Every user has credentials information
> stored in the database. If the user is registered as an Active
> Directory/local user then the framework returns its own 401 response
> triggering IIS to check the credentials against the users using basic
> authentication/NTLM or whatever other authentication protocols are set
> up for IIS.
>
> If the user is registered such that the password is in the database
> then this password is checked by the framework. For active directory/
> local users IIS informs you of the authenticated user in the server
> variables.
>
> In both cases a cookie set on the browser session (database users
> could have a longer cookie) to tell the framework how the user is
> authenticating.
>
> There are a number of details that need to be right to make it secure,
> but that's the gist of it.
>
>
>
>
> We also allow anonymous access to the site. If you're going to be
> using the normal log in process seen on most web sites then this will
> look to IIS like anonymous access and you have to check the user
> settings on each page request.
>
> It should also be possible to write an authentication plug-in to IIS,
> but it's not something we've really looked at. I suspect it'll be a
> lot more complex than the way we've done it.
>
> K
Hi Dave,
Will your users that have a valid AD account be connecting through
workstations that are joined to the domain? I'm trying to understand
whether you would like to preserve the good user experience of
intranet SSO that you normally get with AD credentials in this
scenario.
If so then you want to try NTLM first (anonymous not allowed). This
allows IIS to challenge the browser session for default creds that
might work. If the default creds don't work, i.e. the user's not
logged on with his AD creds. Before IIS returns an error for
unauthenticated access you'd want to trap that and instead initiate a
Basic logon sequence via a redirect to another page. I think I would
probably prefer forms-based authentication for the scenario, but
that's up to you of course.
I don't know if you have to do something like create two versions of
the app in two different VDIRs in order to make this work. I've had
that thought before when trying to figure out how to make IIS use two
completely different forms of AuthN but have never gone through the
process of trying to set it up to see how it works.
HTH.
Dave
|
|
|
|
|