Implementing some kind of Microsoft Passport technology on top of Spectra
would also be kind of cool, and make Spectra the number one choice for
Intranets. Basically what happends is one server is designated as passport
control, and this is the server that everybody logs into. When they've
logged in, passport control records a cookie in the users browser. When I
try and get into a site I'm not logged into, my browser is redirected to the
passport control server, which reads my cookie and checks to see if I'm
allowed into the request site. If I am, the passport control server
encrypts my details and sends them back to the required application by
redirecting my browser. Software on the application can read these
encrypted details and thus log me onto the application. The application
does not then have access to my password, only the passport server has all
the details.
The passport server can then use SiteMinders NT domain authentication. The
main point I'm seeing in this thread is, 'Who much do I trust my
developers?', and this is where I see code reviews as invaluable.
Anyone interested in working on this technology?
-Maddog
WildFusion
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> Sent: 15 March 2001 06:00
>> To: Spectra-Talk
>> Subject: RE: Automatic Login
>>
>>
>> >I think the scheduled process would be unnecessary. If
>> you're offloading
>> >your authentication to NTLM and a user does not exist in
>> the Spectra db, you
>> >would simply create an account (or even be really cool and
>> send them to a
>> >profile page on their first "hit" where they could
>> customize some of their
>> >info)
>> -- Agreed. The more I think about this way of doing
>> things, the more it makes sense. I don't see any obvious
>> security holes... you're not going to be able to access any
>> .cfm templates unless you first get by the webserver
>> security, thus your NT username and password must be
>> entered. Hypothetically I could see a user logging in with
>> their NT username and password and then somehow modifying
>> cgi.auto_user when it's sent to the server, thus letting
>> them access someone elses account if they knew someone
>> elses username... oohh well.
>>
>>
>> >As far as unscrupulous developers go, there's not much
>> protection from them
>> >under any circumstances so no point in complicating things
>> to avoid things
>> >that simply can't be avoided.
>> -- The only way a developer is going to get access to
>> Jeremy's NT password in the aforementioned example is by
>> using a password cracking tool on the local machine or a
>> network sniffer, which hopefully a network admin would notice.
>>
>> Aaron
>>
>>
>>
>>
>>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.