Re: form authentication and webservices



In order to use S4U, you have to configure constrained delegation and make
sure the web server service account is allowed to log in via protocol
transition ("allowed to delegate with any protocol" setting in ADUC). These
are generally not enabled by default, so the expection would be that it
would not work unless someone specifically changed this.

Kerberos delegation is a good thing, but it can be a PITA to configure. MS
has written a bunch of very good (but long) documents on TechNet that
explain the configuration stuff in gory detail.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Abdullah" <Abdullah@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:31FDD378-4F47-4D5A-B978-114E3E1D4C14@xxxxxxxxxxxxxxxx
Gents,
I believe we are narrawing dowing on the following Architecture:
We will be using form autentication on the web site (users are stored in
AD).
We will be using Windows Authentication on the Web Services side (same
users
in AD).

We tried the following code on the web site side but it did not seem to do
the trick.. Any more great feedback? Any special setup we have to do on
the
OS or IIS ?Thanks in advance..

string identity = User.Identity.Name;

int slash = identity.IndexOf( "\\" );
if (slash > 0)
{
string domain = identity.Substring(0, slash);
string user = identity.Substring(slash + 1);
identity = user + "@" + domain;
}

// The WindowsIdentity(string) constructor uses the new
// Kerberos S4U extension to get a logon for the user
// without a password.
WindowsIdentity wi = new WindowsIdentity (identity);
WindowsImpersonationContext wic = null ;
try
{
wic = wi.Impersonate();

// web service call
}
catch ( Exception ex)
{
// Ensure that an exception is not propagated higher in the call
stack.
}
finally
{
// Make sure to remove the impersonation token
if ( wic != null )
wic.Undo();
}


"Joe Kaplan" wrote:

It would be easiest to do this by simply passing the user name as a
parameter in the SOAP body. However, the more "WS*" way to do it would
be
with a header like Dominick suggested. Another option would be to use
Windows auth on the web services and use protocol transition logon to
create
a Windows user identity for the user based on their user name and then
impersonate that.

If the web services are only going to be called by you and aren't going
to
be a public API for other people, then I think I'd just pass the username
as
a parameter, but it is definitely something to think about carefully.
Each
approach implies different assumptions about how things will work and
takes
different dependencies.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Abdullah" <Abdullah@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BE19D96E-0C2A-43ED-BE35-CBECE52F9742@xxxxxxxxxxxxxxxx
well, I think your idea about the ip filter (which I believe is the
same
concept as IP tagging) will solve the authentication problem for sure.
the
only missing piece of the puzzl is how to propagate the identity of the
caller (who signed in using form authentication) to the web services?
The
web
services logic will perform specific job based on the identity of the
caller.. plus, if an intruder managed to get control of the exposed IIS
machine, wouldn't be a trivel matter for him to call into the web
services
then?
Thanks again for your time and helpfull answers..

"Dominick Baier" wrote:

Well - there are several ways to accomplish that.

The easiest is probably to configure an IP filter in IIS so that the
web
services only takes requests from localhost.

You can pass the name of the authenticated client as a parameter or
header.

Since you use active directory, you can also use windows
authenticaiton
for
the web services and restrict access to the windows identity that is
used
to run the web application.


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications
(http://www.microsoft.com/mspress/books/9989.asp)

Dominick
Thanks for your prompt response.. it looks like i had a flow in my
architecture..
I will try to describe to you what I am trying to accomplish and
maybe you
could guide me with an approach..
We're doing an e-business website, form authentication based on an
external active directory. On the same website, we created a bunch
of
webservices that we would like them to be used only by the website.
We
also would like those webservices to know the identity of the caller
to perform some business logic.

Having said all that, what would be your recommendation? Thanks in
advance for your great feedback, you just saved me a lot of running
around :)

"Dominick Baier" wrote:

There is no out of the box support for FormsAuthentication for web
service. FormsAuth uses redirects and cookies - thats very non web
service like.

That said you can implement that by using the FormsAuthentication
API
and cookie support in the client proxy. This involves some testing
and you have to have a strategy how you handle ticket timeouts...

I would rather recommend using basic authentication or WS-Security
with UsernameTokens...

-----
Dominick Baier (http://www.leastprivilege.com)
Developing More Secure Microsoft ASP.NET 2.0 Applications
(http://www.microsoft.com/mspress/books/9989.asp)

Hi.. I am using form authentication on a web site that consumes
web
services. Can the identity of the user that is logged on to the
web
site passed to the web services for the same authentication? if
so,
what would need to be configuered? Thanks a lot,









.