Webservice & integrated windows authentication

21/12/2007 - 10:41 von Christian Havel | Report spam
Wie funktioniert die Authentifizierung genau, wenn ein Webservice mittels der
integrierten Windows Authentifizierung arbeitet?
Wo werden welche Informationen übertragen, und geprüft, wenn ein Client den
Webservice aufruft?
 

Lesen sie die antworten

#1 Frank Dzaebel
21/12/2007 - 12:49 | Warnen spam
Hallo Christian,

Wie funktioniert die Authentifizierung genau, wenn ein Webservice mittels
der
integrierten Windows Authentifizierung arbeitet?
Wo werden welche Informationen übertragen, und geprüft, wenn ein Client
den
Webservice aufruft?



ehe ich das mit meinen eigenen Worten ausdrücke, ist
es sicher besser, das mit geprüften Artikel-Links von technet oder
MSDN o.a. zu machen, wenn Du eine spezielle Frage in einem
Kontext hast, kannst Du ja nochmal nachfragen.

[Explained: Windows Authentication in ASP.NET 2.0]
http://msdn2.microsoft.com/en-us/li...80475.aspx

[IIS Insider - September 2005]
http://www.microsoft.com/germany/te...00965.mspx

[Identitàts- und Zugriffsverwaltung mit Microsoft]
http://www.microsoft.com/germany/te...fault.mspx

[Gewusst wie: Konfigurieren eines XML-Webdienstes für die
Windows-Authentifizierung]
http://msdn2.microsoft.com/de-de/li...zk0tb.aspx
("Wenn die integrierte Windows-Authentifizierung verwendet wird, müssen Sie
die Credentials-Eigenschaft auf
System.Net.CredentialCache.DefaultCredentials festlegen.")

Folgendes aus: [Developing Identity-Aware ASP.NET Applications]
http://www.microsoft.com/technet/se...SPD_1.mspx

Windows-Integrated Authentication:
For most intranet scenarios the recommended approach is to choose
Windows-integrated authentication and the Kerberos authentication protocol
as an end-to-end solution. This approach works well on the Windows platform,
and when you are integrating with other platforms that support the Kerberos
version 5 protocol. The “Intranet Access Management” paper in this series
describes this type of integration with third-party applications and
platforms, such as UNIX, SAP R/3 Application Server, mainframes, J2EE, and
so on.
For applications hosted in the extranet there are several "integrated"
authentication mechanisms that you can use other then the Kerberos protocol
or NTLM. The available authentication protocols include Microsoft Passport,
Secure Sockets Layer (SSL) client authentication, Basic, and Digest
authentication. These mechanisms are fully described in the “Extranet Access
Management” paper in this series. This paper will describe in more detail
how ASP.NET applications in particular can take advantage of the
authentication mechanisms that are implemented in and integrated with IIS.
The important aspect of IIS-integrated authentication mechanisms for
developers is that the ASP.NET application does not need any additional code
in order to perform authentication. The IIS host provides all
authentication. This is a tremendous advantage when an organization is
trying to standardize the development process. Because all authentication is
controlled by configuration on the Web server, there is no code in the
application to standardize.
An additional important aspect of IIS-integrated authentication mechanisms
is that a Windows security context (in the form of an "impersonation token")
is created as a result of every successful authentication. Depending on the
configuration of the ASP.NET application, IIS will attach the impersonation
token to the current request before invoking the ASP.NET application.
Generally, this approach provides a simple and efficient way to make
authorization decisions using a variety of mechanisms.

[Kerberos (Informatik) - Wikipedia]
http://de.wikipedia.org/wiki/Kerber...ormatik%29


ciao Frank
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Ähnliche fragen