La capa de dades: Entity Framework

Per fer una petita introducció, recomano la lectura de les següents entrades de la llinreria MSDN.

1. 
   
   What's New in ADO.NET
2. 
   
   Building N-Tier Applications (Entity Framework)

Un exemple aclaridor de la potencia d'aquest framework la podem veure en una de les seccions a la que ens guia el segon enllaç, "Walkthrough: Serialize Self-Tracking Entities (Entity Framework)" o "Attaching and Detaching Objects (Entity Framework)" o "Working with Self-Tracking Entities (Entity Framework)".

I també estaria bé fer una lectura del que no es recomana a l'hora de fer aplicacions de n-capes, "Anti-Patterns To Avoid In N-Tier Applications", i el que si està bé "N-Tier Application Patterns"

Aprenem més...........!!!

Proveïdor d’Identitats: Un exemple per entendre-ho tot (VI)

(PART V)

Bé doncs, ara implementarem la segona part, entrar des del servei fronterer al servei final, i que aquest rebi les credencials de l’usuari que ha iniciat el procés en l’estació client.

Primer de tot, editarem el fitxer de configuració del servei fronterer i afegirem el següent:

 
Després agreguem una referència al servei final.
 

 
I, tornant al web.config del servei fronterer apliquem la següent modificació:
 

Tot seguit modifiquem la implementació d’ambdós serveis, per tal d’aplicar la funcionalitat que volem demostrar.





En el servei fronterer (Front_End_Service):

public string GetDataUserName()
        {
            //TODO: Change the code below to handle your claims usage.
            IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
            IClaimsIdentity identity = (IClaimsIdentity)principal.Identity;

            SecurityToken st = identity.BootstrapToken;
            if (st == null)
            {
                st = principal.Identities[0].BootstrapToken;
            }

            string _sconf = "WS2007FederationHttpBinding_IService";
            RequestSecurityTokenResponse _rsts = new RequestSecurityTokenResponse();

            STSRPClient c2 = new STSRPClient(st, _sconf);

            Back_End_Service.IServiceChannel cl2 = c2.ClientActAs;

            string res1 = cl2.GetDataUserName();

            cl2.Close();

            return string.Format("Front_End_Service: tu ets {0}{1}{2}" , identity.Name, "\r\n" ,res1);
        }

I en el servei final (Back_End_Service):

public string GetDataUserName()
        {
            //TODO: Change the code below to handle your claims usage.
            IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
            IClaimsIdentity identity = (IClaimsIdentity)principal.Identity;

            return string.Format("Back_End_Service: tu ets {0} i l'actor és {1}", identity.Name, identity.Actor.Name);
        }

I no oblidem importar les llibreries IDP i STS al servei fronterer.


Ara només queda accedir a la consola del ADFS 2.0 i configurar el servei final per tal de que accepti delegació. Per fer-ho, haurem de donar autorització per delegar a l’usuari del pool de connexions on es trobi el servei fronterer dins el servidor d’aplicacions (IIS+WAS). Normalment el servei de xarxa, tot i que no és el més convenient, si volem fer crides des de servidors diferents. És millor utilitzar un usuari del domini, amb permisos d’accés (els necessaris) al AD.
Primer de tot, dins la consola, editem les reclamacions del servei final:

Tot seguit ens posicionem en la pestanya de regles d’autorització de delegació.

Afegim la regla que autoritzarà a l'usuari del pool d'aplicacions del servei fronterer a l' IIS a actuar com a l'usuari que hi ha encaixat en el token que s'ha generat des de la estació client per accedir al servei fronterer i que també ens servirà per accedir al servei final. Això és el que s'anomena "delegar el control l'accés".

L'usuari del servei de xarxa, és el que i ha configurat al pool del servei fronterer a l'IIS. Quan un servei o aplicació té configurat aquest usuari en el seu pool, i accedeix a un recurs de xarxa, l'usuari es converteix dins el domini en l'usuari [domini\nomdehost$], molt important saber-ho. Una altre cosa que hem de fer, es donar permisos d'accés a la clau privada del certificat que utilitzem per signar els tokens a aquest usuari.

Tot seguit, un cop afegida la regla, ens posicionem a les regles de transformació (primera pestanya). Esborrem tot el que hi hagi, i hi afegim dues regles que deixarem passar “reclamacions” del token d’entrada, el que utilitzem per accedir al servei de forma delegada.

Fem el mateix amb el Rol, i finalment tenim:

I ja està, ara només cal provar un altre cop tot el procés, provem i obtenim:

Finalment podem veure com fem traspassar de manera transparent, les credencials de l’usuari fins al servei final. Com que no podem fer un login de l’usuari en el servei fronterer (no podem, desconeixem la contrasenya de l’usuari) utilitzem autoritzacions de delegació per tal d’aconseguir-ho.

Amb aquest senzill exemple, es demostra una de les grans utilitats que pot oferir un gestor d’identitats.

Proveïdor d’Identitats: Un exemple per entendre-ho tot (V)

(PART IV)
Per implementar la negociacio amb el STS i el accés al servei, primer ens crearem un a llibreria en C# i anomenada IDP i li posarem aquesta classe dins: 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IdentityModel.Tokens;
using System.ServiceModel;
using Microsoft.IdentityModel.Protocols.WSTrust;
using System.ServiceModel.Security;

namespace IDP
{
    public static class EndPoints
    {
        public static string baseUri = "http://[idphost]/adfs/services/";
        public static string SSLbaseUri = "https://[idphost]/adfs/services/";
        
        public  static SecurityToken GetTokenFrom_trust_13_usernamemixed(string username, string password, string appliesTo, out RequestSecurityTokenResponse rsts)
        {
            string adrecaSTS = "trust/13/usernamemixed";

            WS2007HttpBinding binding = new WS2007HttpBinding();

            binding.Security.Message.EstablishSecurityContext = false;
            binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
            binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
            binding.Security.Mode = SecurityMode.TransportWithMessageCredential; //https




            WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory(binding, new EndpointAddress(SSLbaseUri + adrecaSTS));
            trustChannelFactory.TrustVersion = TrustVersion.WSTrust13;
            trustChannelFactory.Credentials.UserName.UserName = username;
            trustChannelFactory.Credentials.UserName.Password = password;
            trustChannelFactory.ConfigureChannelFactory();

            WSTrustChannel tokenClient = (WSTrustChannel)trustChannelFactory.CreateChannel();


            //create a token issuance issuance
            RequestSecurityToken rst = new RequestSecurityToken(WSTrust13Constants.RequestTypes.Issue);
            //Relying Party’s identifier
            rst.AppliesTo = new EndpointAddress(appliesTo);
            //call ADFS STS
            SecurityToken token = tokenClient.Issue(rst, out rsts);

            return token;
        }
        
        public static SecurityToken GetTokenFrom_trust_13_windows(string appliesTo, out RequestSecurityTokenResponse rsts)
        {
            string adrecaSTS = "trust/13/windows";

            WS2007HttpBinding binding = new WS2007HttpBinding();

            binding.Security.Message.EstablishSecurityContext = false;
            binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
            binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
            binding.Security.Mode = SecurityMode.Message;
            binding.Security.Message.NegotiateServiceCredential = true;




            WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory(binding, new EndpointAddress(baseUri + adrecaSTS));
            trustChannelFactory.TrustVersion = TrustVersion.WSTrust13;
            trustChannelFactory.ConfigureChannelFactory();

            WSTrustChannel tokenClient = (WSTrustChannel)trustChannelFactory.CreateChannel();


            //create a token issuance issuance
            RequestSecurityToken rst = new RequestSecurityToken(WSTrust13Constants.RequestTypes.Issue);
            //Relying Party’s identifier
            rst.AppliesTo = new EndpointAddress(appliesTo);
            //call ADFS STS
            SecurityToken token = tokenClient.Issue(rst, out rsts);

            return token;
        }

  
    }
}

Aquesta classe ens ajuda a obtenir tokens del STS per un servei en concret. El primer mètode, a partir d’unes credencials entrades per l’usuari, i el segon utilitzan les credencials del usuari loginat al SO (usuari Windows).

I ara, per tal de facilitar la creació de clients de Serveis (Agents de servei), que puguin actuar amb o sense delegació, utilitzarem una altre llibreria que ens facilitarà la feina. Aquesta la farem en VB.Net i li direm STS. Dins hi posarem la següent classe. Hem de fer les referències.

Imports System.IdentityModel.Tokens
Imports System.ServiceModel
Imports System.ServiceModel.Description
Imports Microsoft.IdentityModel.Protocols.WSTrust
Imports System.ServiceModel.Channels
Imports System.ServiceModel.Security
Imports System.ServiceModel.Security.Tokens
Imports System.Text

Public Class STSRPClient(Of T)
    Implements IDisposable
#Region "Members"
    Private _st As SecurityToken
    Private _factory As ChannelFactory(Of T)
#End Region
    ''' 

    ''' Contructor per generar Client a partir del fitxer de configuració
    ''' 
    ''' 
''' 
''' 
    Sub New(ByVal st As SecurityToken, ByVal bindingConfiguration As String)
        Create(st, bindingConfiguration)
    End Sub
  
    Private Sub Create(ByVal st As SecurityToken, ByVal bindingconfiguration As String)
        Me._st = st
        _factory = New ChannelFactory(Of T)(bindingconfiguration)
        _factory.ConfigureChannelFactory()
    End Sub

    Public Sub Close()
        _factory.Close()
    End Sub

    Public ReadOnly Property Client As T
        Get
            Return _factory.CreateChannelWithIssuedToken(_st)
        End Get
    End Property
    Public ReadOnly Property ClientActAs As T
        Get
            Return _factory.CreateChannelActingAs(_st)
        End Get
    End Property

#Region "IDisposable Support"
    Private disposedValue As Boolean ' To detect redundant calls

    ' IDisposable
    Protected Overridable Sub Dispose(ByVal disposing As Boolean)
        If Not Me.disposedValue Then
            If disposing Then
                ' TODO: dispose managed state (managed objects).
            End If
            If Me._factory.State <> CommunicationState.Closed Then
                _factory.Close()
            End If
            _st = Nothing
            ' TODO: free unmanaged resources (unmanaged objects) and override Finalize() below.
            ' TODO: set large fields to null.
        End If
        Me.disposedValue = True
    End Sub

    ' TODO: override Finalize() only if Dispose(ByVal disposing As Boolean) above has code to free unmanaged resources.
    'Protected Overrides Sub Finalize()
    '    ' Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.
    '    Dispose(False)
    '    MyBase.Finalize()
    'End Sub

    ' This code added by Visual Basic to correctly implement the disposable pattern.
    Public Sub Dispose() Implements IDisposable.Dispose
        ' Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.
        Dispose(True)
        GC.SuppressFinalize(Me)
    End Sub
#End Region

End Class

Un cop compilades, farem les referències a aquestes en l’aplicació client.

1. Obtenir token per l’usuari
2. Crear client amb el token
3. Invocar Servei
4. Escriure el resultat

Imports System.IdentityModel.Tokens
Imports Microsoft.IdentityModel.Protocols.WSTrust

Public Class Form1

    Private Sub BInvoke_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BInvoke.Click

        Dim adrecaservei As String = "http://localhost/Front_End_Service/Service.svc"

        ' App.config - Nom de la configuració del binding del client
        Dim conf As String = "WS2007FederationHttpBinding_IService"


        ' Primer hem d'obtenir un token de seguretat del IDP pel servei

        Dim rsts As New RequestSecurityTokenResponse
        Dim st As SecurityToken = IDP.EndPoints.GetTokenFrom_trust_13_usernamemixed(Me.TxtUser.Text, Me.TxtPwd.Text, adrecaservei, rsts)

        ' Un cop el tenim em de fer-lo servir per accedir-hi i invocar les seves operacions

        Dim clirp As New STS.STSRPClient(Of Front_End_Service.IServiceChannel)(st, conf)
        Dim client As Front_End_Service.IServiceChannel = clirp.Client

        Dim response As String = client.GetDataUserName()

        clirp.Close()
        clirp.Dispose()


        Me.TextBox1.AppendText(response + vbNewLine)

    End Sub
End Class

Diagrama de seqüències del event del botó.

Ara ja podem compilar i provar. De moment només invoquem el primer servei.



Invocació amb unes credencials incorrectes

 
Invocació amb credencials correctes.
 

Proveïdor d’Identitats: Un exemple per entendre-ho tot (IV)

(PART III)

Obrim l ‘administrador del IIS. Podem veure els serveis del ADFS i els nostres serveis.

Primer de tot, afegim un pool nou de connexions, que funcioni amb el .NET Framework 4.0. No és necessari però evitarem problemes (que no explicaré perquè depenen de la combinació de versions de SO + IIS). Aquest nou pool és el que utilitzaran els nostres nous serveis.

Bé ara ja podem tornar al Visual Studio, i picar una mica de codi.

Primer de tot podem mirar els web.config dels serveis i esbrinar que vol dir tot el que ha posat el procés de federació. És una bona pràctica.

Un cop assabentats d’aquesta nova tecnologia, modificarem els serveis.

Primer modificarem la Interfície d ‘ambdós, perquè quedi de la següent manera:

....

    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        string GetDataUserName();
    }

....

Tot seguit implementem la interfície en ambdós serveis.

Front_End_Service

using System.Threading;
using Microsoft.IdentityModel.Claims;
namespace Front_End_Service
{
    public class Service : IService
    {
         public string GetDataUserName()
        {
            IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
            IClaimsIdentity identity = (IClaimsIdentity)principal.Identity;
            return string.Format("Front_End_Service: tu ets {0}", identity.Name);
        }
    }
}

Back_End_Service

using System.Threading;
using Microsoft.IdentityModel.Claims;
namespace Back_End_Service
{
    public class Service : IService
    {
        public string GetDataUserName()
        {
            IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
            IClaimsIdentity identity = (IClaimsIdentity)principal.Identity;
            return string.Format("Back_End_Service: tu ets {0} i l'actor és {1}", identity.Name, identity.Actor.Name);
        }
    }
}

Després ens situarem a l’ aplicació client i crearem una referència al servei “Front_End_Service”.

Un cop fet això modificarem el fitxer “app.config”, per tal de posar el endpoint del STS que consumirà el token de seguretat.



Cercarem el “tag” següent :

 
 
I el substituirem per aquest, el trobarem comentat en el mateix app.config:
 

 

Podríem utilitzar-ne un altre, però aquest, és una bona opció. Una bona pràctica seria entendre els endpoints del STS.

Tot seguit crearem un formulari semblant a aquest, amb unes entrades de usuari i contrasenya , un botó per invocar el servei, i una consola per mostrar el resultat.

I, implementarem el codi que farà possible la invocació del servei. Sabem que necessitem un token de seguretat per accedir al servei, i el token ens l’ha de donar el STS a través del ADFS 2.0.
 

Proveïdor d’Identitats: Un exemple per entendre-ho tot (III)

(PART II)

Tot seguit anirem a la consola de gestió del ADFS 2.0 i configurarem l’autentificació del servei “Front_End_Service” el fronterer, el que dona accés al client a la capa de negoci.

Un cop entrem hem de seguir uns passos molt senzills.

Pot ser que en aquest punt tinguem problemes de “certificats”. Si es així triem la segona opció, i anem a buscar de meta dades de federació al directori del projecte.

Li posem un nom.

Li donem permís a tots el usuaris. Això vol dir que qualsevol usuari de l’ Active Directori podrà accedir al servei un cop s’hagi validat.

En el següent pas entrarem les regles d’autorització, i configurarem els “claims” o reclamacions o atributs o propietats, digueu-li com voleu, que s’enviaran des del IDP al RP, o sigui des del servei STS al RP STS, que són els nostres serveis.

Aquí li diem que envií la propietat de l’usuari SAM-Account-Name com a un “claim” de tipus Name, i els grups als que pertany com a “claims” de tipus Role.

Aquí li diem que envií la propietat de l’usuari SAM-Account-Name com a un “claim” de tipus Name, i els grups als que pertany com a “claims” de tipus Role.

Finalment tenim les regles dels claims que enviarem d'un usuari autenticat i autoritzat. En la pestanya del mig tenim les regles d'autoritzacio d'accés al servei.

Aquest procés l’hem de fer amb ambdós serveis.

Proveïdor d’Identitats: Un exemple per entendre-ho tot (II)

(PART I)

Tot seguit el que cal es federar els serveis amb el nostre IDP (identity Provider), que en el nostre cas és ADFS 2.0 RC.

 
Tot seguit la seqüència de federació del servei.
 

El “STS WS-Federation metadata document location” normalment està al servidor on hem instal•lat el ADFS 2.0:

https://[idphost]/FederationMetadata/2007-06/FederationMetadata.xml

Podem xifrar o no el token de seguretat. Si ho fem podem generar un certificat o triar-ne un existent .
Tot seguit veiem tots els tipus de “claims” que ofereix el Security Token Service (STS) a través del IDP.

Finalment, podem programar una tasca que ajusta la configuració de federació si es produeixen canvis en el IDP.

Aquest procés de federació l’hem de fer per ambdós serveis.

Proveïdor d’Identitats: Un exemple per entendre-ho tot (I)

Per fer referència a tota una arquitectura de gestió d’identitats que fan servir aplicacions actives (winforms, windows presentation foundation, windows communication services, workflow services, aplicacions RIA, windows mobile, etc) i aplicacions passives (ASP.Net, aplicacions Web en general), unificada, centralitzada i basada en estàndards, que millor que presentar un escenari i fer-ne el desenvolupament.

Com que d’exemples d’aplicacions passives n’està ple a Internet, ens centrarem en un escenari actiu.

Descripció Escenari: Suposem un domini d’aplicació format per una aplicació client desenvolupada en winforms, que accedeix a un servei distribuït (WCF), i aquest a un altre servei distribuït (WCF). Fins ara cap cosa nova. Però ara hi posarem unes petites regles:

• L’ usuari s’haurà d’autenticar per accedir a l’aplicació winforms, al servei fronterer i al darrer. Amb un cop n’hi hauria d’haver prou, no?
• Ha de suportar que els serveis definits estiguin en nivells (servidors) diferents, inclòs en xarxes diferents i dominis diferents (en l’exemple no ho farem per falta de recursos, però és del tot possible i fàcil de fer).
• La transmissió de credencials entre aplicacions actives ha de ser segura.
• Els components de seguretat que fan referència a l’autentificació, autorització i transmissió de credencials entre aplicacions han de ser transparents pel desenvolupador. Afegir els components ha de ser un automatisme de posada en producció dins un entorn empresarial, seguin les normes establertes.

Per poder desenvolupar l’ escenari, disposarem d’una serie de recursos:

• Dos servidors amb Windows 2008 R2, IIS + WAS, Windows Identity Foundation (WIF). En un dels dos hi instal•larem AD+ADFS 2.0 RC (hi ha molta documentació per Internet). Frameworks fins al 3.5.1. Podem instal.lar el 4.0 però a hores d’ara no és una versió publicada.
• Una estació client amb Windows 7 o XP, amb els frameworks i WIF mencionats.
• Una eina de desenvolupament com pot ser VS2008 o VS2010 Beta o RC, instal.lada en una de les màquines anteriorment citades. (Jo personalment, instal•lo un Visual Studio a cada servidor de desenvolupament).

Si ens fixem bé en les dependències, els serveis depenen directament de la capa de seguretat per funcionar, i per tant les aplicacions client indirectament també necessiten d’aquesta per utilitzar-los.

I per tant la seqüència que haurà de seguir l’ aplicació client per accedir al servei frontera serà:

1. Demanar usuari i contrasenya.
2. Connectar amb la capa de seguretat, presentar les credencials d’usuari i sol•licitar un token per accedir al servei. Si està autoritzat, aquesta li servirà un token amb la informació que necessita de l’usuari el servei per funcionar, per ser operatiu.
3. L’agent del servei (client del servei, Proxy del servei) presentarà el token a aquest, per tal de que doni accés a la invocació de les seves operacions.
4. El servei veurà la identitat de l’usuari que està executant l’aplicació client. Si volem transmetre-la cap al servei final, em de tenir en compte algunes coses. Primer de tot, l’usuari que executa el procés del servei al servidor, és el que hi hagi definit en el pool del IIS on estigui allotjat el servei (Normalment NetWorkService). Per tant, hem de guardar el token que arriba sense desxifrar, per poder-lo utilitzar per invocar al servei final, ja que aquest porta les credencials del usuari tal i com les entén la capa de seguretat. I a l’agent del servei final li hem de dir que encara que l’usuari executor del procés sigui el NetWorkService, actuí com a l’usuari que ha iniciat a l’aplicació client. Aquesta sol•licitud de delegació la gestiona la capa de seguretat i aquesta l’ha de permetre.
5. Finalment, al servei final hem de tenir dues identitats. Un Actor que serà el NetWorkService i un usuari principal que serà l’usuari que ha iniciat l’aplicació client. O sigui el NetWorkService actua com a l’usuari de l’aplicació client en el servei final, el qual pot està allotjat a la Xina. Transmetem una tarja d’identitat des de l’ inici fins al final.

Anem per feina: Implementació

Primer de tot creem una solució al Visual Studio (jo utilitzo el 2010). Si hem instal•lat bé el WIF SDK, tindrem uns templates i un Add-in que ens facilitaran la feina. Alhora de crear WCF Serveis preparats per treballar amb identitats i per posar-los en producció amb un gestor d’identitats (IDP) com pot ser ADFS 2.0.

Si ens hi fixem els serveis els ubiquem al IIS local. La solució final ha de tenir una aparença semblant a la de la imatge següent.

Dos serveis habilitats per treballar amb “claims” i una aplicació Winforms.

WCF (Windows Communication Foundation)

Windows Communication Foundation (WCF) de Microsoft és el model de programació unificat per a la construcció d'aplicacions orientades a serveis. Permet als desenvolupadors construir la seguretat, la fiabilitat, i la transacció a través de solucions que integrin les plataformes i interoperar amb les inversions existents.

Fonaments de WCF
Windows Communication Foundation (WCF) és un conjunt d'APIs per a la creació de sistemes que s'envien missatges, entre els serveis i els clients dels serveis. La mateixa infraestructura i API s'utilitzen per crear aplicacions que es comuniquen amb altres aplicacions en el mateix equip o en una màquina que resideix en una altre empresa i s'accedeix a través d'Internet.

Missatges i extrems (Messaging and Endpoints)
WCF es basa en el concepte de comunicació basat en missatges, i tot el que pot ser modelat com un missatge (per exemple, una petició HTTP o un missatge de MSMQ) poden ser representats de manera uniforme en el model de programació. Això permet una API unificada a través de diferents mecanismes de transport.
El model distingeix entre clients, que són aplicacions que inicien la comunicació, i serveis, que són aplicacions que esperan als clients per comunicar-se amb ells i respondre a aquesta comunicació.
Els missatges s'envien entre extrems.
S’han d’establir criteris, valorar i definir tota la informació necessària per a l'intercanvi de missatges.
Un servei exposa una sol licitud o més punts finals (així com a zero o més paràmetres d'infraestructura), i el client genera un punt final que és compatible amb un dels criteris de valoració del servei. Descriu un punt final que es basa en la manera en que els missatges han de ser enviats o intercanviats. Un servei pot exposar la informació com a metadades que els clients puguin utilitzar per generar clients (proxys) i contractes per tal de poder establir la comunicació amb les piles (conjunt de canals) del servei.

Protocols de comunicació

Un element de la comunicació és el protocol de transport que viatjara per la pila (canal). Es poden crear més mecanismes de transport utilitzant extensions del WCF.

Un altre element necessari en la pila de comunicació és la codificació que s'especifica de quina manera cada missatge està formatat. WCF proporciona les següents codificacions:

Codificació de text, una codificació interoperable.
Mecanisme de transmissió del missatge d'Optimització (MTOM) de codificació, que és una forma interoperable, eficient per a l'enviament de dades binaries no estructurades d'un servei.
Codificació binària per a la transferència eficient.

Es poden generar més mecanismes de codificació (per exemple, una codificació de compressió) fent ús dels punts d'extensió del model d ‘operacions de WCF.

Patrons missatge

WCF admet diversos models de missatgeria, incloent sol licitud-resposta, en un sol sentit, i la comunicació dúplex. Les diferents modalitats de transport donen suport a les diferents modalitats de missatges i, per tant l'API de WCF en temps d’execució afageix seguretat i fiabilitat en l’intercanvi de missatges.

Termes WCF

Altres conceptes i termes utilitzats en la documentació de WCF Són els següents.

Missatge

Un missatge és una unitat autònoma de dades que podrà constar de diverses parts, inclòs un cos i les capçaleres.

A service is a construct that exposes one or more endpoints, with each endpoint exposing one or more service operations.Un servei és una construcció que exposa un o diversos paràmetres, amb una exposició de cada punt final i operacions de servei.

Un punt final és una construcció en la que viatgen els missatges enviats o rebuts (o ambdós). Es compon d'un lloc (una adreça) que defineix on es poden enviar missatges, l'especificació d'un mecanisme de comunicació (vinculant) que es descriu com s'han d'enviar els missatges, i una definició d'un conjunt de missatges que poden ser enviats o rebuts (o ambdós) en aquest lloc (un contracte de serveis) que descriu el que es pot enviar el missatge.
Un servei de WCF s'exposa al món com una col lecció de punts finals (canals).

Aplicació de punt final

Un punt final exposat per la sol licitud i que correspon a un contracte de serveis executats per l'aplicació.

Infraestructura de punt final.

Un punt final que s'exposa a través de la infraestructura per facilitar la funcionalitat que es requereix o és facilitada pel servei que no es refereixi a un contracte de serveis.

Per exemple, un servei pot tenir un punt final que proporciona la infraestructura d'informació de metadades.

Adreça

Una adreça específica el lloc on es reben missatges. S'especifica com un Uniform Resource Identifier (URI). La part de l'esquema de noms URI és el mecanisme de transport a utilitzar per arribar a l' adreça, com ara HTTP i TCP. La jerarquia de la URI conté una ubicación única i el format depèn del mètode de transport. El punt final de l' adreça li permet crear adreces úniques per a cada punt final en un servei, o, en determinades condicions, es pot compartir una adreça en els extrems.

L'exemple següent mostra una adreça mitjançant el protocol net.tcp amb un port no predeterminat:

net.tcp://server.domain.com:8000/DalDBIService/Service.svc

Element vinculant

Un element vinculant representa una part de la unió, com ara el transport, una codificació, una implementació d'una infraestructura a nivell de protocol (com WS-ReliableMessaging), o qualsevol altre component de la comunicació pila.

Controladors de Funcionament

Un controlador és un component que controla diversos aspectes de temps d'execució d'un servei, un punt final, una operació, o un client. Els controladors s'agrupen d'acord a l'àmbit d'aplicació: controladors comuns afecten tots els punts finals a nivell general, el servei només afecta els controladors relacionats amb els aspectes de serveis, al punt final només afecten els controladors relacionats amb les propietats de punt final, i el funcionament a nivell de conductes afecten a les diferents operacions. Per exemple, un controlador és la regulació, que especifica com reacciona quan un un excés de missatges amenacen amb desbordar la seva capacitat de manipulació. Un controlador variable, d'altra banda, els controls només els aspectes relatius a les variables, com ara com i on trobar una credencial de seguretat.

Enllaços proporcionats pel sistema

WCF inclou diferents sistemes d'enllaços. Es tracta de col leccions d'elements vinculants que estan optimitzats per a situacions específiques. Per exemple, el WSHttpBinding està dissenyat per a la interoperabilitat amb els serveis que implementen diferents especificacions WS-*. Aquests enllaços predefinits estalvien temps presentant únicament les opcions que poden ser correctament aplicades a la situació específica. Si un predefinit vinculant no compleix els seus requisits, es pot crear el seu propi vinculant.

Configuració versus codificació

El control d'una sol licitud es pot fer ja sigui a través de la codificació, a través de la configuració, o mitjançant una combinació d'ambdós. La configuració té l'avantatge de permetre que algú que no sigui el promotor (per exemple, un administrador de xarxa) pugui configurar els paràmetres de servei de client i sense haver de recompilar el codi escrit. Configuració no només li permet establir els valors com les adreces de punt final, sinó que també permet un major control per la qual cosa li permet afegir punts finals, fixacions, i comportaments. Codificació permet als desenvolupadors mantenir un control estricte sobre tots els components del servei o client, i qualsevol ajustament realitzat a través de la configuració pot ser inspeccionat i, si cal anul lat des del codi.

Explotació del servei

Un servei és un procediment d'operació que es defineix en una part de codi que implementa la funcionalitat per a una operació. Aquesta operació està exposada als clients com els mètodes d'un client WCF. El mètode pot tornar un valor, i pot tenir un nombre opcional d'arguments, o no tenen arguments, i tornar sense resposta. Per exemple, una operació que funciona com un simple "Hola" es pot utilitzar com una notificació de la presència d'un client i començar una sèrie d'operacions.

Contracte de servei

El contracte de serveis utilitza múltiples llaços junts en les operacions relacionades amb una sola unitat funcional. El contracte pot definir els ajustos de nivell de servei, tals com l'espai de noms del servei, el corresponent contracte de devolució de trucada, i altres ajustaments. En la majoria dels casos, el contracte es defineix per la creació d'una interfície de programació en l'idioma de la seva elecció i l'aplicació de la ServiceContractAttribute atribuit a l’ interfície. El codi de servei real es el resultat d’ aplicar la interfície.

Un contracte d'operació es defineix el tipus de retorn i paràmetres d'una operació. En crear una interfície que defineix el contracte de serveis, que significa un contracte d'operació mitjançant l'aplicació dels OperationContractAttribute atribuir a cada mètode de definició, que és part del contracte. Les operacions poden ser modelades tenint un sol missatge, o tenint un conjunt de tipus de missatges. En aquest últim cas, el sistema determinarà el format dels missatges que han d'intercanviar per l'operació.

Un missatge contracte descriu el format d'un missatge. Per exemple, declarar els elements que han d'anar a les capçaleres i al cos, quin nivell de seguretat s'ha d'aplicar als elements del missatge, i així successivament.

Culpa contracte(Excepció)

Un contracte de culpa es pot associar amb un servei d'operació per indicar els errors que es poden retornar a la persona que truca (client). Una operació pot tenir zero o més defectes associats a ella.. Aquests errors (transmesos en SOAP) es basa en les fallides com les excepcions en el model de programació.

Contracte de dades

Els tipus de dades que utilitza un servei, haurà de ser descrita a les metadades per tal que puguin interoperar amb altres per al servei. Les descripcions dels tipus de dades són coneguts com les dades del contracte, i els tipus es poden utilitzar en qualsevol part d'un missatge, per exemple, com a paràmetres o tipus de retorn. Si el servei és senzill utilitzant només els tipus, no hi ha necessitat d'utilitzar les dades explícitament els contractes.

Allotjament

Un servei ha d'estar allotjat en algun procés. Un host és una aplicació que controla la vida útil del servei. Els serveis poden ser acollits o auto-administrats per un procés d'acollida existent.

Auto-servei allotjat

Un auto-és un servei allotjat que s'executa dins d'un procés de sol licitud, que el desenvolupador ha creat. (Classe ServiceHost)

Procés d'acollida

Un procés d'acollida és una aplicació que està dissenyat per acollir els serveis. Aquests inclouen Internet Information Services (IIS), Serveis d'activació de Windows (WAS), i serveis de Windows. En aquests escenaris amfitrió, l'amfitrió controla la vida del servei. Per exemple, si utilitza IIS, pot crear un directori virtual que conté el servei de muntatge i arxiu de configuració. Quan es rep un missatge, IIS inicia el servei i controla la seva vida.

Instàncies

Un servei té un model d'instància. Hi ha tres models d'instàncies: "únic", en què un sol objecte servei CLR atent tots els clients, "per trucada", en la qual un nou objecte CLR es crea per tractar a cada client de trucada, i "en cada període de sessions", en què un conjunt CLR d'objectes es creen, un per a cada període de sessions. L'elecció d'un model d'instància depèn dels requisits de l'aplicació i el patró d'ús d'espera del servei.

Aplicació client

Una aplicació client és un programa que els intercanvis de missatges amb un o més extrems. L'aplicació client comença per la creació d'una instància d'un client de WCF i els mètodes, funcions i propietats que pot invocar del servei WCF. És important assenyalar que una única aplicació pot ser tant un client i un servei.

Canal

Un canal és una aplicació concreta d'un element vinculant. La unió representa la configuració, i el canal està associat amb l'aplicació de la configuració. Per tant, la configuració defineix un canal associat a cada element vinculant. El conjunt de canals defineixen la pila de canals que es poden utilizar per invocar el servei (canal pila).

WCF client

Un client de WCF és una aplicació client que exposa a la construcció de les operacions dels serveis com els mètodes (al. NET Framework, llenguatge de programació de la seva preferència, tals com Visual Basic o Visual C #). Qualsevol aplicació pot acollir un (o més) WCF client, inclosa una sol licitud que allotja un servei. Per tant, és possible crear un servei que inclou el conjunt operacions dels clients altres serveis.

Un client de WCF pot ser generat automàticament utilitzant l'eina d'utilitat ServiceModel metadades (Svcutil.exe) i apuntant en funcionament un servei que publica metadades.

Metadades

Les metadades d'un servei ens descriuen les característiques del servei que una entitat externa a d'entendre per comunicar-se amb el servei. Les metadades poden ser consumits per la utilitat de les metadades ServiceModel Tool (Svcutil.exe) per generar un client de WCF i que acompanya a la configuració d'una aplicació client pot utilitzar per interactuar amb el servei.

Les metadades exposades pel servei inclou l'esquema XML de documents, que defineixen les dades del contracte del servei, i els documents WSDL, que descriuen els mètodes del servei.

Quan està activada, les metadades del servei es generen automàticament pel conjunt d'operacions pel servei d'inspecció i els seus criteris de valoració. Per publicar les metadades d'un servei, s’ha d’especificar explícitament en el comportament del servei.

Seguretat

WCF inclou la seguretat a la confidencialitat (xifrat de missatges per prevenir escoltes), integritat (els mitjans per a la detecció de la manipulació amb el missatge), l'autenticació (els mitjans per a la validació dels servidors i clients), i l'autorització (el control d'accés als recursos). Aquestes funcions són proporcionades per qualsevol dels mecanismes de seguretat existents, com TLS sobre HTTP (també conegut com HTTPS), o mitjançant l'aplicació d'una o més dels diversos WS-* especificacions de seguretat.

Per la seguretat del transport

Seguretat poden ser proporcionades per un dels tres modes: mode de transport, el mode de missatge de seguretat, i el transport amb el mode de missatge credencial. El mode de seguretat de transport s'especifica que la confidencialitat, integritat, autenticació i són proporcionades pels mecanismes de la capa de transport (per exemple, HTTPS). Quan s'utilitzi un transport com HTTPS, d'aquesta manera té l'avantatge de ser eficient en el seu acompliment, i siguin ben compreses per la seva prevalença a Internet. El desavantatge és que aquest tipus de seguretat s'aplica per separat en cada tram en la ruta de comunicació, fent de la comunicació sensibles a un atac “d’ home al mig”.

Per la seguretat en el missatge

Missatge Especifica el mode de seguretat que la seguretat és proporcionada per l'aplicació d'una o més de les especificacions de seguretat, tals com l'especificació anomenada "de seguretat de Serveis Web: SOAP Message Security" (disponible a http://go.microsoft.com/fwlink/?LinkId = 94684). Cada missatge conté els mecanismes necessaris per garantir la seguretat durant el seu trànsit, i de permetre que els receptors per detectar la manipulació i per a desxifrar els missatges. En aquest sentit, la seguretat es encapsulada dins de cada missatge, d'extrem a extrem a través de múltiples salts. Perquè la informació de seguretat es converteix en part del missatge, també és possible incloure diversos tipus de credencials amb el missatge (es refereix a les reclamacions). Aquest enfocament també té l'avantatge de permetre que el missatge pot viatjar de forma segura a través de qualsevol transport, inclouent salts entre origen i de destí. El desavantatge d'aquest enfocament és la complexitat dels mecanismes de xifrat, i les implicacions que porta la seva correcta execució.

Transport amb el mode de missatge de credencial de seguretat

Aquest mode utilitza la capa de transport per proporcionar confidencialitat, autenticació i integritat dels missatges, mentre que cadascun dels missatges pot contenir múltiples credencials (reclamacions) requerida pels receptors del missatge.