«

I am in search of some suggestions regarding how I should emplement security
in a system being developed.

System architecture:
A web application is exposed to the internet. Behind a firewall is a series
of web services. The web services communicate with a SQL server 2000
database through stored procedures. Users access the web application over
an SSL connection, and the web application accesses the web services over an
SSL connection. We limit access to the web application through forms
authentication.

My design dilemna:
There should be some authentication mechanism between the web application
and the web services. In the future we may develop other applications or
allow other vendors to use our web services. So my question is, are there
recommended ways to authenticate an application to a web service?

I'm not inclined to use WSE because I'm not aware of toolkits for much
beyond .net development and we want a relatively easy method of using the
web services with technologies other than .net.

I am searching for some sort of standard mechanism that can be relatively
easily implemented. I could role my own solution but in the event that 3rd
party vendors will use my web services, they will need to understand my
implementation details where as sdks are probably already available for
standard approaches.

The only thing that I'm aware of that is relatively standard across toolkits
is something transport level like HTTP Basic authentication. This is also
probably fine fine from a security perspective when combined with SSL.

You then have to decide if you want to implement a trusted subsystem or a
delegated model. A trusted subsystem essentially uses fixed service
accounts from the web service client side to access the web services. If
the front of the web service client will take requests from many different
clients, it is responsible for providing any intermediary security to the
web service.

In a delegated model, you would essentially take the credentials of the
authenticated user and pass them through the web application tier to the web
service tier, which would then apply security rules directly to the user.

Both approaches have their advantanges and disadvantages.

Joe K.

"Jeremy Chapman" <please@Idontlikespam> wrote in message
news:eSVvql$...
>I am in search of some suggestions regarding how I should emplement
>security in a system being developed.
>
> System architecture:
> A web application is exposed to the internet. Behind a firewall is a
> series of web services. The web services communicate with a SQL server
> 2000 database through stored procedures. Users access the web application
> over an SSL connection, and the web application accesses the web services
> over an SSL connection. We limit access to the web application through
> forms authentication.
>
> My design dilemna:
> There should be some authentication mechanism between the web application
> and the web services. In the future we may develop other applications or
> allow other vendors to use our web services. So my question is, are there
> recommended ways to authenticate an application to a web service?
>
> I'm not inclined to use WSE because I'm not aware of toolkits for much
> beyond .net development and we want a relatively easy method of using the
> web services with technologies other than .net.
>
> I am searching for some sort of standard mechanism that can be relatively
> easily implemented. I could role my own solution but in the event that
> 3rd party vendors will use my web services, they will need to understand
> my implementation details where as sdks are probably already available for
> standard approaches.
>

If the client application uses forms authentication can that be delegated to
the web services which uses basic authentication? Where can I find some
information on how to implement delegation like this?

"Joe Kaplan (MVP - ADSI)" <> wrote
in message news:%23JQdyx$...
> The only thing that I'm aware of that is relatively standard across
> toolkits is something transport level like HTTP Basic authentication.
> This is also probably fine fine from a security perspective when combined
> with SSL.
>
> You then have to decide if you want to implement a trusted subsystem or a
> delegated model. A trusted subsystem essentially uses fixed service
> accounts from the web service client side to access the web services. If
> the front of the web service client will take requests from many different
> clients, it is responsible for providing any intermediary security to the
> web service.
>
> In a delegated model, you would essentially take the credentials of the
> authenticated user and pass them through the web application tier to the
> web service tier, which would then apply security rules directly to the
> user.
>
> Both approaches have their advantanges and disadvantages.
>
> Joe K.
>
> "Jeremy Chapman" <please@Idontlikespam> wrote in message
> news:eSVvql$...
>>I am in search of some suggestions regarding how I should emplement
>>security in a system being developed.
>>
>> System architecture:
>> A web application is exposed to the internet. Behind a firewall is a
>> series of web services. The web services communicate with a SQL server
>> 2000 database through stored procedures. Users access the web
>> application over an SSL connection, and the web application accesses the
>> web services over an SSL connection. We limit access to the web
>> application through forms authentication.
>>
>> My design dilemna:
>> There should be some authentication mechanism between the web application
>> and the web services. In the future we may develop other applications or
>> allow other vendors to use our web services. So my question is, are
>> there recommended ways to authenticate an application to a web service?
>>
>> I'm not inclined to use WSE because I'm not aware of toolkits for much
>> beyond .net development and we want a relatively easy method of using the
>> web services with technologies other than .net.
>>
>> I am searching for some sort of standard mechanism that can be relatively
>> easily implemented. I could role my own solution but in the event that
>> 3rd party vendors will use my web services, they will need to understand
>> my implementation details where as sdks are probably already available
>> for standard approaches.
>>
>
>

You should be able to. Since forms authentication requires that you capture
the user's plain text credentials in order to implement the login, you
should be able to store those and then forward them in your web service
proxy using the Credentials property. The .NET web service proxy base class
(which uses HttpWebRequest under the hood) will negotiate Basic auth (or
Digest or IWA) automatically if credentials are supplied.

Delegation is more tricky if you don't have plain text credentials, as in
that case you need to use a Windows OS feature like Kerberos delegation in
order to do the same thing. That is how that scenario is typically
implemented in situations that use IWA on the front end. The basic
architecture principle is the same though.

Joe K.

"Jeremy Chapman" <please@Idontlikespam> wrote in message
news:...
> If the client application uses forms authentication can that be delegated
> to the web services which uses basic authentication? Where can I find
> some information on how to implement delegation like this?
>