de9me . via .NET 247 wrote:
> - Client is a C# WinForm .NET app
>
> -Webservice is hosted on a linux machine running BEA WebLogic
>
> I want the client app to respond to the server challenge for
authentication:
> a) Using https (SSL), which would prompt user for a PKI
certificate.
> b) A server challenge for BASIC authentication, which would
pop-up a logon window requesting username/password.
> c) BASIC authentication over SSL, which would prompt for PKI
cert and pop-up logon window requesting username/password.
>
> This is the behavior that Internet Explorer provides to end users.
How do I provide this same functionality in a C# .NET client app?
Therefore, how do you capture/interpret a server challenge (non IIS web
servers) or are there methods/libraries you can use to do the same
thing that IE provides?

a lot of webservers provide stub authentication routine ... for
implementation of client authentication. a frequent proposal in the
past has been to radius-enable such stub routines ... then the
infrastructure can use the full power of radius based
authentication/authorization/permissions/administration/etc operations
for managing their clients.

There are a number of standard radius implementations that accept some
asserted entity ... which is then authenticated from information
maintained at radius and then the permissions &/or policies associated
with that entity are established.

standard radius have been shared-secret based supporting clear-text
password or challenge/response protocols. there have also been
enhancements to radius for supporting digital signature verification
where the shared-secret password registration is replaced with public
key registration (all the administration and business practices are
preserved for relationship real-time management).
[url]http://www.garlic.com/~lynn/subpubkey.html#radius[/url]

the simple pulic key in lieu of shared-secret password is effectively a
certificate-less based operation
[url]http://www.garlic.com/~lynn/subpubkey.html#certless[/url]

depending on whether shared-secret clear-text or non-clear-text
authentication is used ... the mechanism may or may not require an
encrypted SSL channel.

Somewhat the design point for certificate-based public keys was the
offline email environment of the early 80s. The recipient dialed up
their (electronic) post office, exchanged email, hung up and were then
possibly faced with handling first time communication with a complete
stranger. This is the letters of credit paradigm from the sailing ship
days .... how does the relying party determine anything about complete
stranger on initial communication ... when there was no direct access
to either local or remote information available to the relying party.

The early 90s saw some certificate-oriented operations attempting to
deal with x.509 identity certificates and the inability to predict what
information some unknown relying party in the future might require from
a complete stranger. The tendency was to look at grossly overloaded the
identity certificate with enormous amounts of privacy information.

By the mid 90s, some infrastructures were starting to realize the x.509
identity certificates overloaded with enormous amounts of privacy
information represented serious liability and privacy concerns. There
was then some retrenchment to relying-party-only certificates
[url]http://www.garlic.com/~lynn/subpubkey.html#rpo[/url]

basically certificates that contained little more than an index to some
kind of account/entity record (where all the real information was)
bound to a public index/key. However, since this fundamentally violated
the target environment that certificates were designed to address
(offline enviornment with first time communication between total
strangers), it was trivial to demonstrate that stale, state
certificates were redundant and superfluous. The subject generated a
message, digitally signed the message and then packaged the message,
the digital signature, and the digital certificate and sent it off to
the relying party. The relying party extrated the record index/key from
the initial message and retrieved the message (including the originally
registered public key). The onfile public key was then used to validate
the digital signature. The inclusion of the stale, static digital
certificate in the transmission was redundand and superfluous.

The redundant and superfluous, stale, static digital certificate did
represent something of an issue in proposal for use in payment
transactions of the period. A typical payment message is on the order
of 60-80 bytes. Even the typical relying-party-only certificate from
the period was on the 4k-12k bytes. While the stale, static certificate
was redundant and superfluous it did have the potential of creating
enormouos payload bloat in the payment networks, increasing
transmission requirements by a factor of one hundred times.