Principal flowing and caching

[James]

Hy,

I'm currently working on an web app with ASP.NET 2.0.
Here are my needs :
-I would like a custom form login screen.
-My user information is kept in AD.
-My ASP.NET application must access internal WebServices which require IIS
Intregrated Windows Authntication.
I current understanding is that I must use a call to LoginUser in order to
get a Kerberos Token which I may use to pass my network credentials to the
webservices
(using CredentialCache.DefaultCredentials).
I haven figured out how to cache the kerberos token during ASP.NET calls.
I also would like a scalable solution.
Is my approach ok... is there an alternative ?

Thank you,

James

 

[Joe Kaplan \(MVP - ADSI\)]

Why use forms-based login? This is SO much easier to do with Windows auth.
Essentially, you just get Kerberos auth working and enable delegation and it
just works.

Note that it is also possible to do what you want via protocol transition
(S4U) auth if your servers and AD are 2003. In this case, can get a
WindowsIdentity for the user with just their user name (userPrincipalName)
and impersonate that during your web service call. If you configure
protocol transition and constrained delegation, that will still work. Note
that you may also need to give your process account "act as part of the
operating system" privilege for this to work. In theory you don't, because
you can delegate without necessarily needing to have an impersonation level
token locally, but in practice you often do as the web services plumbing
sometimes reads local files that require impersonation.

If you want call LogonUser (using the user's password), then you can do the
same thing and avoid needing Kerberos delegation. The issue there, as you
have pointed out, is that you then need to cache that token or cache the
user's plaintext credentials in case you need to make subsequent calls.
Personally, I like the staight windows auth or protocol transition approach
better as I think they are both a little cleaner. I especially don't like
having to hold onto a user's plaintext credentials (or ever even getting
them in the first place for that matter).

Joe K.

 

[James]

Thanks for your help,

The reason we are using form-based login is that the application gives
access to very sensitive data and we want the added gate of having to login
in order to prevent a user acquiring access to sensitive data by using an
unlock PC.

Is it possible to cache the Kerberos Principal ??... the principal is
serializable so it should be able possible to put it in a out-of-process
cache but from my understanding the ticket is only good for one PC so caching
would not work in a farm scenario...??!!

If I use protocol transition... what would be the best way to cache securly
the user ID ?

Thank you,

James

 

[Joe Kaplan \(MVP - ADSI\)]

You could use Basic authentication instead of forms auth if you want to
force a reauthentication and don't want to allow SSO. You'll need to be
using SSL anyway if this data is really confidential, as forms auth isn't
really safe without SSL either and confidential data should never be
transmitted on the wire unencrypted in the first place.

Regarding caching the WindowsIdentity, as long as you keep it in memory, it
should be ok. I'm not certain if you'll get good results if the object is
serialized as it wraps an OS handle. You could try it though.

For caching the ID for protocol transition, this would depend on the auth
method you were using. If you used forms auth, I'd probably put the data in
forms auth ticket and perhaps sign/encrypt it to prevent tampering and
inspection. User names are generally not considered secret in the same way
that passwords are, but you would not want a hacker to be able to supply a
different user identity than the one they authenticated with. Additionally,
you can cache a WindowsIdentity generated by S4U the same as one generated
via LogonUser (or Windows auth with Basic or IWA).

Joe K.