Plataforma

Microsoft .NET

Juan Francisco Adame Lorite

Ingeniera de servicios de
Internet (Julio 2003)
Juan Francisco Adame Lorite

Presentacin
La plataforma .NET de Microsoft es la ltima apuesta de esta compaa para
la integracin de servicios y aplicaciones de Internet. Es una plataforma hecha a la
semejanza de la plataforma J2EE de Sun (no es un delito admitirlo, ni hace de
menos al software de Microsoft). La plataforma de Sun ha sentado una buena base
no slo comercial sino de filosofa moderna de sistema de informacin, que
Microsoft ha reutilizado para adecuar sus productos de desarrollo a un nuevo
entorno. Microsoft ha intentado recuperar el tiempo perdido con este software.
La plataforma est orientada a Internet y los entornos distribuidos. Por eso
hace especial hincapi en la distribucin de cdigo en diferentes ubicaciones y a la
comunicacin de estas partes de cdigo mediante objetos remotos o servicios Web
entre otras tecnologas.
La naturaleza distribuida de la plataforma obliga a hacer un especial
esfuerzo en lo que a seguridad y confianza se refiere. Todo el cdigo y servicios se
desarrollan bajo unas caractersticas apropiadas de seguridad y confiabilidad.
La plataforma se ha orientado mucho a nuevas tecnologas como XML
ampliamente aceptadas por una gran parte del sector de las tecnologas de la
informacin. Esto permite que las aplicaciones y servicios desarrollados en la
plataforma sean fcilmente integrables con otros servicios y aplicaciones, incluso de
otras plataformas.
El mbito de aplicacin de la plataforma es muy extenso, desde servicios
Web, aplicaciones Windows y aplicaciones Web hasta componentes y bibliotecas de
todo tipo.

Estructura de la plataforma
La plataforma se compone principalmente de dos partes:
Common Language Runtime
.NET Framework Class library
El primero es el entorno de ejecucin, es el cliente de la plataforma que
analiza y ejecuta el cdigo. Es el elemento anlogo al JVM de Java (Java Virtual
Machina), salvo con la diferencia que el cdigo ejecutado si es binario compilado en
este caso.
El segundo es el conjunto de bibliotecas de la plataforma integradas en ella
que permiten al desarrollador hacer uso de las principales funciones y
caractersticas de la plataforma. Es el elemento anlogo a las JFC de Java (Java
Foundation Classes).
A diferencia de la plataforma Java no existe un lenguaje definido para el
desarrollo. Si bien todo cdigo es traducido a una especie de metacdigo llamado
MSIL, similar al Bytecode de Java; ste como en el caso de Java no es apto para el
desarrollo. La plataforma slo exige una serie de tipos, estructuras y formas
comunes que todo lenguaje debe implementar y modelar de alguna manera en su
sintaxis, que le permita compilar despus su cdigo a MSIL. Microsoft distribuye la
plataforma con cuatro lenguajes de desarrollo: Visual Basic, Manager C++, C# y
J#. Aunque actualmente muchos fabricantes han anunciado la salida al mercado de
sus lenguajes de desarrollo para la plataforma .NET, como es el caso de Borland y
Delphi.
El Common Type System (CTS) define como son declarados, usados y
administrados los diferentes tipos en tiempo de ejecucin. Esto es muy til porque
define los tipos posibles y su forma lo que facilita la implementacin de estos tipos
en los diferentes lenguajes de la plataforma .NET. El CTS define los tipos nativos o
de valor y los tipos referenciados (tanto a datos, como los delegados y eventos),
los tipos miembro (mtodos, funciones, constructores, atributos) y sus
Juan Francisco Adame Lorite

modificadores, as como los delegados y eventos, arrays, interfaces, punteros

Todo lenguaje compatible o integrable en la plataforma debe ser concordante y
coherente con estas especificaciones. Un resumen del CTS se puede encontrar en
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconthecommontypesystem.asp
La siguiente figura muestra el esquema de tipos que define el CTS:

Para permitir interactuar entre los elementos sin importar el lenguaje en que
se implementan, estos elementos deben mostrar slo aquellas caractersticas que
son comunes a todos los lenguajes. Por este motivo el Common Language
Specification (CLS) se define como requisito de interfaz (hacia dentro se puede
utilizar el CTS completo) de todos los elementos de la plataforma. Para que dos
elementos implementados en lenguajes distintos puedan interactuar entre s, sus
interfaces pblicos deben cumplir los requisitos de tipos especificados en el CLS. El
CLS es un subconjunto de especificaciones reducidas del CTS. El CLS permite a los
desarrolladores de diferentes lenguajes compartir cdigo y componentes. Un
resumen del CLS se encuentra en
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconwhatiscommonlanguagespecification.asp

Common Language Runtime (CLR)

El Common Language Runtime (CLR) es un agente o cliente de la plataforma
que gestiona los procesos de ejecucin y los servicios de estos procesos. Es anlogo
al JVM de Java con la salvedad que se ejecuta cdigo binario compilado especfico y
no cdigo interpretado. La misin del CLR es efectuar la carga de este cdigo,
gestionar sus necesidades de memoria y recursos, comprobar el acceso y privilegios
disponibles y requeridos para el cdigo, comprobar la robustez y la seguridad de
tipos concordantes con el CTS.
El cdigo es compilado haciendo referencia y uso del agente CLR, por lo que
se denomina managed code (cdigo administrado). El CLR se encarga de la gestin
de memoria: reserva y liberacin de recursos, referencias nulas, errneas o zonas
de tipo privado; tiempo de vida de los objetos y liberacin de recursos automtico,
control y gestin de la seguridad.
El CLR permite tambin la ejecucin de cdigo o partes del cdigo de tipo no
administrado (unmanaged code), cuando el cdigo tiene los privilegios de seguridad
necesarios para la ejecucin de cdigo no administrado (mucho ms restrictivos
que el cdigo administrado). De esta manera es posible interactuar con antiguas
bibliotecas como las del sistema (WIN32) o con tipos COM, que son cdigo no
administrado.
Juan Francisco Adame Lorite

La figura muestra el esquema de la estructura de la plataforma. El agente de

ejecucin (CLR) se ejecuta sobre el sistema operativo y es el nico intrprete entre
las aplicaciones de cdigo administrado y el sistema operativo. El cdigo
administrado hace uso de las clases de la biblioteca .NET Framework y de las
propias bibliotecas o externas del desarrollador. El cdigo no administrado hace sin
embargo uso directo del sistema operativo, sin pasar por la supervisin del CLR.
Existe un segundo CLR que el es que ejecuta los servicios Web y aplicaciones
ASP.NET; este agente CLR es especfico para funcionar sobre Internet Information
Server (IIS) y hace uso de las funcionalidades adicionales y restricciones de este
entorno. En este caso el agente no se comunica con el sistema operativo si no que
lo hace con ste ltimo mediante el IIS.
Puede encontrarse ms informacin sobre el CLR en:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconcommonlanguageruntimeoverview.asp.

.NET Framework Class Library

La .NET Framework Class Library es la biblioteca de la plataforma. La
Framework ofrece un conjunto de clases, interfaces y tipos reusables con las
funcionalidades ms bsicas y comunes de la plataforma. Contiene los tipos
utilizados en el desarrollo de la plataforma.
Permiten implementar:
Aplicaciones de consola. (System.Console) Este espacio de nombres
permite utilizar y hacer uso de los flujos de entrada, salida y error
bsicos de la aplicacin.
Aplicaciones basadas en formularios Windows.
(System.Windows.Forms) Este espacio de nombres nos permite hacer
uso de la GUI de Windows: ventanas, botones,
Aplicaciones Web ASP.NET y servicios Web (System.Web) Este
espacio de nombres nos permite implementar aplicaciones Web
basadas en formularios ASP y desplegar servicios Web.
Acceso a fuentes de datos (System.Data)
Acceso de ficheros y flujos (System.IO)

Juan Francisco Adame Lorite

Adems define interfaces de funcionalidades bsicas como el IComparable

para establecer los operadores de comparacin de elementos, el IEnumerable para
hacer uso de la coleccin en un bucle foreach, ICloneable para soportar el clonado
de objetos, y clases base como BaseCollection para implementar colecciones
especficas de elementos mediante herencia.
Puede encontrarse ms informacin en:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/cpref_start.asp.

El proceso de ejecucin administrado

El proceso de ejecucin de un proceso de la plataforma .NET es el siguiente:
El compilador del lenguaje especfico elegido para el desarrollo compila el
cdigo fuente al lenguaje intermedio MSIL. Este cdigo MSIL junto con los recursos
de otros tipos necesarios para la ejecucin y los metadatos del cdigo son
encapsulados en un archivo Portable Executable (PE).
El siguiente cuadro muestra un ejemplo de cdigo MSIL:
.method public hidebysig instance class System.Object Pop() il managed {
// Code size 43 (0x2b)
.maxstack 4
.locals ([0] class System.Object V_0, [1] int32 V_1)
IL_0000: ldarg.0
IL_0001: ldfld int32 Stack::m_size
IL_0006: brtrue.s IL_000e
IL_0008: newobj instance void ['mscorlib']System.NullReferenceException::.ctor()
IL_000d: throw
IL_000e: ldarg.0
IL_000f: ldfld class System.Object[] Stack::m_stack
IL_0014: ldarg.0
IL_0015: dup
IL_0016: ldfld int32 Stack::m_size
IL_001b: ldc.i4.1
IL_001c: sub
IL_001d: dup
IL_001e: stloc.1
IL_001f: stfld int32 Stack::m_size
IL_0024: ldloc.1
IL_0025: ldelem.ref
IL_0026: stloc.0
IL_0027: br.s IL_0029
IL_0029: ldloc.0
IL_002a: ret
} // end of method 'Stack::Pop'
En el momento en que se solicita la ejecucin del fichero PE el compilador
Just In Time (JIT) extrae el cdigo MSIL y con ayuda de los metadatos compila a
cdigo binario dependiente de la mquina. Ese cdigo binario se almacena en un
cach de binarios para futuras ejecuciones.
El agente CLR toma ahora el control sobre la ejecucin de la aplicacin.
Primero comprueba que recursos y privilegios requiere la aplicacin (de acceso a
memoria o disco, de cdigo no administrado, de seguridad y concordancia de
tipos,), estos se obtienen de los metadatos del cdigo. Si el usuario que ejecuta y
el cdigo ejecutado tienen los suficientes permisos y privilegios exigidos se procede
a la ejecucin, si no se produce una excepcin y no se ejecuta el cdigo.
Durante la ejecucin el CLR proporciona y administra los recursos de la
aplicacin, gestiona el tiempo de vida de sus objetos, comprueba la seguridad y
concordancia de los tipos, dispara excepciones,
Existe ms informacin sobre los ficheros PE en:
http://www.windowsitlibrary.com/Content/356/11/1.html.
Juan Francisco Adame Lorite

El recolector de basura
En los lenguajes orientados a objetos el tiempo de vida de los mismos ya era
controlado por el compilador, pero an as haba ocasiones en que esto no era
suficiente y parte de la memoria poda quedar desreferenciada y no era liberada.
Java resolvi este problema con el recolector de basura (Garbage Collector,
GC) y la plataforma .NET hace uso del mismo concepto.
El tiempo de vida de toda instancia de una clase (objeto) es el tiempo
transcurrido entre la llamada a su constructor y la llamada a su destructor y la
liberacin de los recursos de los que haca uso. El momento de creacin es
controlado en el cdigo por el usuario. Sin embargo, la destruccin del objeto no la
lleva a cabo el usuario, el CLR ejecuta cada cierto tiempo un agente llamado
recolector de basura que comprueba que elementos no estn ya referenciados para
liberar los recursos que consumen (principalmente de memoria). La afirmacin de
que la destruccin de recursos no est controlada por el usuario no es del todo
cierta, aquellos recursos que implementen el interfaz IDisposable poseen el mtodo
Dispose que libera los recursos que posea la instancia sin necesidad de llamar al
recolector (slo los recursos asociados, la propia instancia es eliminada por el
recolector de basura).
Los objetos de tipo no nativo o de valor, son llamados objetos referenciados,
son instancias de clases. El elemento de cdigo es una referencia al heap del
proceso donde se almacena realmente la instancia. Cada cierto tiempo el GC inicia
el proceso de recoleccin de basura, primero comprueba que elementos del heap
no estn apuntados por ninguna referencia del cdigo o que referencias estn fuera
ya del mbito de ejecucin actual. Todos esos elementos son eliminados del heap.
Si el nmero de elementos eliminado es muy alto, la memoria se compacta para
aprovechar el espacio y se actualizan las referencias en el cdigo. Es por este
motivo muy importante hacer uso del operador fixed cuando trabajemos con
punteros en cdigo no administrado, para informar al GC que el elemento
referenciado apuntado no debe moverse en el proceso de compactacin a fin de
que el puntero no referencie de forma errnea. Puede verse un ejemplo de
programacin no administrada donde se comprueba este efecto en:
http://www.codeproject.com/csharp/unsafe_prog.asp.
Tambin es posible que existan elementos muy grandes en el heap, cuando
esto es as la compactacin del heap se hace muy lenta y costosa y repercute en el
rendimiento de la aplicacin. Estos elementos muy grandes son almacenados en un
heap especial que no es compactado nunca.
Para mejorar la eficiencia del recolector de basura, existen tres niveles en el
heap en los que se distribuyen los objetos segn su tiempo de vida, de ms jvenes
a ms antiguos. Cuando no hay espacio en el heap de nivel 0 para almacenar un
nuevo elemento, se llama al GC y todos los objetos que sobrevivan al proceso de
recoleccin y/o compactacin se pasan al nivel 1. Cuando el nivel 1 se colapse se
repite el mismo proceso y se pasaran al nivel 2. El nivel 2 es el de mayor nivel.
Esto es muy eficiente porque los elementos tienen tiempos de vida parecidos
segn el mbito de cdigo al que pertenecen (por ejemplo todas las variables
locales de un mtodo) y de esta manera se eliminan a la vez afectando a un solo
nivel del heap.
Ms informacin sobre el recolector de basura en:
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/default.aspx.
http://www.yasd.com/tutorials/c_sharp/chap17_1.htm.

Assemblies
Los assemblies (ensamblados) son los bloques bsicos de las aplicaciones,
ellos son la unidad fundamental de despliegue, control de versiones, reutilizacin,
mbito y permisos de seguridad. Un assembly es una coleccin de tipos y de
recursos integrados de manera y forma que son la unidad lgica de funcionalidad.
Juan Francisco Adame Lorite

El assembly provee al CLR de la informacin necesaria en forma de metadatos de

los tipos implementados y su interpretacin, por lo que un tipo no puede existir
fuera del contexto de un assembly.
El assembly es el elemento bsico de salida del compilador. Es el elemento
ejecutado por el CLR.
Todo assembly contiene una versin, assemblies con versiones distintas son
distintos para el CLR. El origen, el autor y la versin del assembly se pueden
garantizar mediante firmado.
El assembly es la unidad de seguridad de cdigo bsica, los privilegios se le
conceden al cdigo en funcin del origen, autor, versin, del assembly.
El assembly es la entidad de mbito bsica, dos tipos iguales en assemblies
distintos son tipos distintos, un tipo no tiene sentido fuera del contexto de un
assembly.
Un assembly se compone de:
Por un manifiesto en forma de metadatos del assembly: nombre,
versin, cultura, firma,
Metadatos del cdigo, donde se definen los tipos de forma
concordante con el CTS.
Cdigo MSIL.
Un conjunto de recursos, aunque stos pueden ser separados del
assembly en mdulos para facilitar la descarga del assembly.

Los assemblies compartidos se despliegan en el Global Assembly Cache

(GAC). Estos assemblies deben estar firmados. Dos versiones de un mismo
assembly pueden desplegarse en el GAC y la adecuada es escogida por el CLR. Las
assemblies declaran con que versiones anteriores son compatibles para poder ser
escogidas por el CLR cuando la versin exacta no exista en el GAC.
Se puede encontrar ms informacin sobre assemblies en:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconassemblies.asp.

Metadatos
Los metadatos son informacin declarativa que define y especifica el cdigo
del assembly. Los metadatos aaden informacin adicional a la deducible del
cdigo, o definen esta informacin para que evitar que tenga que ser deducida del
cdigo (por un elemento o agente que no entienda ese lenguaje, por ejemplo).
Los metadatos facilitan la interaccin entre diferentes lenguajes. Estos
metadatos definen los tipos del assembly para que puedan ser utilizados por otros
lenguajes. As al leer el interfaz de los tipos desde los metadatos el lenguaje no
debe saber en que fue realizado pues slo se limita a lo que los metadatos le
indican.
Los metadatos definen cada tipo y miembro del cdigo de una manera
neutral. Los metadatos almacenan la siguiente informacin:
Descripcin del assembly:
Identidad (nombre, versin, cultura, llave pblica de firmado)
Juan Francisco Adame Lorite

Los tipos exportados

Otros assemblies de los que este depende y sus versiones
Permisos y privilegios necesarios para ejecutar
Descripcin de tipos:
Nombre, visibilidad, clases base e interfaces implementados
Miembros: atributos, propiedades, campos, eventos, tipos
anidados
Atributos:
Informacin descriptiva adicional que modifica la definicin,
interpretacin o modelado de tipos y miembros
Los metadatos de este ltimo tipo se introducen en el cdigo mediante los
atributos:
[WebMethod(Description="Put in your search string then press Invoke.")]
public DataSet Search(string searchParam)
{ }

[Serializable]
public class Searcher
{ }

Seguridad en la plataforma .NET

Existen 3 mecanismos de seguridad en la plataforma .NET. Cada uno de
ellos es definido en funcin de unos elementos y es gestionado de distinta manera:
Identity. Los privilegios se asignan en funcin de los metadatos de
identidad (nombre, versin, cultura, autor, clave pblica de
firmado,) del assembly a ejecutar.
Code Access Security. Dentro de la descripcin en metadatos del
assembly entre los metadatos descriptivos y los atributos se indican
que privilegios y permisos requiere el assembly para ejecutar y
cuales, an tenindolos, no desea que se le asignen.
Role-based security. La aplicacin corre sobre un sistema en que
cada usuario posee unos privilegios y permisos. Estos privilegios y
permisos se definen por el administrador.
La ejecucin final de la aplicacin o servicio, y los permisos y privilegios con
que sta corra dependern de estos tres elementos (de la interseccin de ellos).
Si un elemento de cdigo necesita un permiso para ejecutar, ese permiso
debe de estar asignado tanto a ese elemento como a todos los que le llaman. Es
decir los privilegios deben estar otorgados en todos los assemblies que se llaman.
Por ejemplo, si el assembly A llama o hace uso del assembly B y este ltimo
requiere del permiso P, slo ejecutar si A tambin tiene asignado este permiso.
Se puede encontrar ms informacin sobre seguridad en la plataforma .NET
en:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconnetframeworksecurity.asp.

Identity security
Es el mecanismo encargado de otorgar permisos y privilegios en funcin de
los metadatos de identidad del assembly. El mbito, el conjunto de cdigo y la
unidad bsica de granulado es el assembly.
El equipo tiene asignadas unas polticas de seguridad. En estas polticas se
definen que privilegios se asignan a cada assembly en funcin de algunos o algn
metadato de identidad. Por ejemplo, los assemblies cuya zona de origen (lugar
donde se ubica el assembly) sea Internet no perteneciente a los sitios seguros de
Internet Explorer, no tendr privilegios para escribir en disco, ver propiedades del
sistema, Estos metadatos de identidad pueden ser el nombre del assembly, la
Juan Francisco Adame Lorite

versin, el autor del assembly (se comprueba por la clave pblica de firmado), la
zona de ubicacin del assembly, la URL de ubicacin del assembly,
Puede que un assembly est afectado por ms de una de estas reglas de
seguridad, si es as el assembly recibe los permisos de ejecucin unin de todos los
otorgados por cada regla.
Adems se definen tres diferentes polticas y una cuarta opcional. Se
denominan de empresa, de equipo, de usuario y de dominio de la aplicacin. La
primera es comn para todo el dominio, la segunda es comn para todo el equipo,
la tercera es propia de cada usuario y la cuarta de cada dominio de aplicacin (de
cada aplicacin, sta es opcional). Los privilegios resultantes para cada assembly
son la interseccin de los otorgados por cada poltica.
En el siguiente ejemplo podemos observar que el cdigo con clave pblica de
firmado dada, cuyo nombre de assembly sea Microsoft.App y que el autor sea
Microsoft recibir por un lado permisos de lectura en el directorio c:\Microsoft y por
el otro de escritura en dicho directorio. La aplicacin tendr privilegios de lectura y
escritura en el directorio a no ser que alguna de las otras dos polticas (empresa o
usuario) no los tenga:

Code access security

Los privilegios y permisos de acceso al cdigo se definen especficamente en
el cdigo, en los metadatos del propio assembly. Lo que se definen van a ser dos
cosas, los privilegios que se exigirn estar otorgados para la ejecucin de la
aplicacin y en segundo lugar los que se denegarn en la ejecucin si ya estuviesen
otorgados. Por ejemplo, mi aplicacin puede requerir para ejecutarse
correctamente permisos de escritura en el directorio C:\MyApp, luego no se
ejecutar si la seguridad de tipo Identity no le ha otorgado este permiso. De la
misma manera mi aplicacin no va a hacer uso de otro directorio que no sea ese,
luego puedo denegar el acceso de cualquier tipo a cualquier otra parte del disco, y
aunque la seguridad de tipo Identity le haya otorgado este permiso la aplicacin no
lo poseer y ser ms segura (frente a bugs que pueda alguien aprovechar de
forma maliciosa, por ejemplo).
Estos permisos se establecen en los metadatos del assembly en dos puntos:
en el cdigo (imperativos), o en los metadatos de descripcin del assembly
(declarativos).
Los permisos declarativos se declaran como atributos en el cdigo tambin,
pero en el assembly los almacenan en los metadatos de descripcin del mismo.
Hacen referencia a todo el assembly, no a una parte del cdigo. Indican que
Juan Francisco Adame Lorite

permisos son necesarios para ejecutar el assembly (si no, el CLR no lo ejecuta) y
cuales se deniegan (aunque la seguridad de tipo Identity los haya otorgado la
aplicacin no los poseer). Se comprueban en tiempo de carga antes de ejecutar la
aplicacin. Tambin es posible solicitar permisos de forma optativa, si no se
otorgan se proceder a ejecutar la aplicacin en este caso y deberemos comprobar
si han sido otorgados de forma imperativa
//If it is not granted the application will fail to start
[assembly : UIPermissionAttribute (SecurityAction.RequestMinimum)]
//If it is not granted the application will still run
[assembly : SecurityPermissionAttribute (SecurityAction.RequestOptional
,Flags=SecurityPermissionFlag.UnmanagedCode)]
// The entire assembly will be blocked from accessing this drive.
[assembly : FileIOPermissionAttribute (SecurityAction.RequestRefuse
,Read=C:\\)]
Los permisos imperativos o solicitados de forma imperativa se solicitan en el
propio cdigo y se comprueba si se han otorgado mediante el cdigo. Son por lo
tanto especficos a una parte del cdigo y al desarrollo particular de la ejecucin de
la aplicacin. Se comprueban en tiempo de ejecucin.
try {
FileIOPermission myPermission = new FileIOPermission
(FileIOPermissionAccess.AllAccess,@"c:\\");
myPermission.Demand();
}
catch (SecurityException ex) {
MessageBox.Show(Security Exception: +ex.Message);
}

Role-based security
Hasta ahora solo hemos comprobado los privilegios de las entidades de
cdigo. Pero adems de estos permisos y privilegios existe un elemento ms que
influye en estos: el usuario de la aplicacin.
Aparecen entonces dos nuevos elementos en la arquitectura el autentificador
y el autorizador.
El autentificador es el elemento que indica que usuario es el que est
accediendo a la aplicacin o servicio. En el caso de aplicaciones de formularios
Windows es el propio sistema operativo Windows, en el caso de servicios Web y
aplicaciones Web es el Internet Information Server. Aunque en ambos se casos se
puede buscar una va alternativa de autentificacin propia.
El autorizador es el elemento que se encarga de otorgar permisos y
privilegios en funcin del usuario autentificado. La autorizacin se realiza de forma
imperativa en el cdigo haciendo uso de las clases Identity que define la identidad
del usuario y Principal que define su pertenencia a grupos. Cada autentificador
declara subtipos (el sistema operativo Windows define WindowsPrincipal y
WindowsIdentity) de estos que se pueden instanciar en la ejecucin del cdigo para
saber que usuario est ejecutando ese cdigo y autorizarle o no.
WindowsIdentity MyIdentity = WindowsIdentity.GetCurrent();
If (MyIdentity.IsGuest) {}
If (MyIdentity.IsAnonymous) {}
If (MyIdentity.IsSystem) {}
String Str=MyIdentity.AuthenticationType;
Str=MyIdentity.Name;
WindowsPrincipal MyPrincipal = new WindowsPrincipal(MyIdentity);
If (MyPrincipal.IsInRole(Administradores)) {}
Juan Francisco Adame Lorite

Seguridad en ASP.NET

Esta figura muestra el proceso de autentificacin y autorizacin en

aplicaciones ASP.NET y servicios Web. Toda peticin pasa por un proceso doble de
autentificacin y autorizacin, el del Internet Information Server y el del agente
CLR de ASP.NET.
En los puntos 2 y 3 se autentifica y autoriza al usuario para acceder a un
recurso que a continuacin se comprueba es una aplicacin ASP.NET o servicio Web
por lo que se pasa la ejecucin de la aplicacin al agente CLR de ASP.NET.
Este agente provee de nuevos mecanismos de autentificacin y autorizacin
especficos, 5 y 6, que son controlados por el propio cdigo de la aplicacin o
servicio.
Finalmente es posible que se intente acceder a un nuevo recurso que
requiera autentificacin y autorizacin, punto 7, en ese caso se hace uso de la
propia del agente CLR ASP.NET, se utiliza la propia identidad obtenida en 5 o se
impersonaliza con una identidad especfica.
La arquitectura habitual de una aplicacin ASP.NET o servicio Web, es la de
autentificarse en 2 como usuario annimo, y que el IIS permita en 3 el acceso
annimo al recurso ASP.NET. En 4 observamos que la identidad que se pasa al
agente CLR ASP.NET es la definida como usuario annimo de IIS (IUSR_MACHINE).
Es en 5 donde se realiza la autentificacin real por diferentes medios como el
servicio Passport de Microsoft, haciendo uso de la de Windows (siempre ser el
usuario annimo de acceso por IIS que es la pasada al agente CLR ASP.NET) o
mediante formularios Web, en la que el cdigo define la propia identidad y principal
del usuario. En 6 el cdigo autoriza a la identidad obtenida del punto 5. Y el acceso
a recursos externos, punto 7, se realiza mediante autentificacin Windows (usuario
annimo) o impersonalizando la peticin a un usuario que sabemos tiene acceso al
recurso.

Nuevas aplicaciones y tecnologas

Aplicaciones de formularios Windows
Conserva la GUI habitual de coger y arrastrar elementos para disear el
aspecto de los formularios. No hay cambios significativos salvo que el sistema de
Juan Francisco Adame Lorite

mensajes de las aplicaciones MFC y Windows API 32 se sustituye por el concepto de

evento y delegado.
public class EventIssuer {
public delegate void EventDelegate(object from, EventArgs args);
public event EventDelegate myEvent;

public void issueEvent(EventArgs args) {

myEvent(this, args);
}
}

EventIssuer ei;
ei.myEvent += new EventIssuer.EventDelegate(handleEvents);

Public void handleEvents(object sender, System.EventArgs e){
//Accin a realizar cuando se lance el evento
}

this.button1.Click += new System.EventHandler(this.button1_Click);

private void button1_Click(object sender, System.EventArgs e)
{
net.xmethods.www.CurrencyExchangeService Servicio = new
net.xmethods.www.CurrencyExchangeService();
float num = (float) Servicio.getRate("euro","us");
label1.Text=num.ToString();
}
Ms informacin en la pgina:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vbcon/html/vboricreatingstandaloneappsvb.asp.

Servicios Web
Es el nuevo tipo de aplicacin soportado por la plataforma. Microsoft se ha
orientado claramente a esta tecnologa con la plataforma .NET y es la principal
innovacin.
Definido bajo los estndares de SOAP para el intercambio de objetos
mediante mensajera XML, de WSDL para la definicin de interfaces de servicios
Web y de UDDI para la publicacin de servicios. Al acogerse a estndares no
propietarios y adoptados por las otras plataformas (J2EE en especial) esta
plataforma se puede integrar con otras mediante esta tecnologa.
El servicio Web es un subtipo de la clase System.Web.Services.WebService y
que indica que mtodos exporta mediante el atributo WebMethod. Esto permite
crear automticamente el archivo WSDL, mediante la firma de cada mtodo
definido como servicio, y la publicacin en el directorio UDDI.
namespace MyWebService {
using System;
using System.Web.Services;

public class MyStringReverse: WebService {

[WebMethod(Description="Reverse String")]
public String ReverseString ( String InString ) {
// Check null String
if ( InString == null ) return null;
Int32 intSize = InString.Length;
char[] arrayInString = InString.ToCharArray();
char[] arrayOutString = new char[intSize];
for (Int32 i = 0 ; i < intSize ; ++i) arrayOutString[i] =
arrayInString[intSize-i-1];
return new String(arrayOutString);
}
}
}
La aplicacin cliente, es decir la que hace uso del servicio Web, hace
peticiones a travs de una clase proxy. Es una clase que tiene el mismo interfaz
Juan Francisco Adame Lorite

que el servicio Web pero cuya implementacin de cada mtodo son las llamadas al
servicio Web. Esta clase se genera automticamente desde el archivo WSDL.
//------------------------------------------------------------------------------
// <autogenerated>
// This code was generated by a tool.
// Runtime Version: 1.0.2914.16
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </autogenerated>
//------------------------------------------------------------------------------

//
// This source code was auto-generated by wsdl, Version=1.0.2914.16.
//
using System.Diagnostics;
using System.Xml.Serialization;
using System;
using System.Web.Services.Protocols;
using System.Web.Services;

[System.Web.Services.WebServiceBindingAttribute(Name="MyClassSoap",
Namespace="http://tempuri.org/")]
public class MyClass : System.Web.Services.Protocols.SoapHttpClientProtocol {

[System.Diagnostics.DebuggerStepThroughAttribute()]
public MyClass() {
this.Url = "http://localhost/ASP.NET/MyWebService.asmx";
}
[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Add
",
Use=System.Web.Services.Description.SoapBindingUse.Literal,
ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
public int Add(int a, int b) {
object[] results = this.Invoke("Add", new object[] {
a,
b});
return ((int)(results[0]));
}

[System.Diagnostics.DebuggerStepThroughAttribute()]
public System.IAsyncResult BeginAdd(int a, int b, System.AsyncCallback
callback, object asyncState) {
return this.BeginInvoke("Add", new object[] {
a,
b}, callback, asyncState);
}

[System.Diagnostics.DebuggerStepThroughAttribute()]
public int EndAdd(System.IAsyncResult asyncResult) {
object[] results = this.EndInvoke(asyncResult);
return ((int)(results[0]));
}
}
La aplicacin cliente slo debe instanciar la clase proxy y llamar al mtodo
que se precise. De forma sncrona:
MyClass mycls = new MyClass();
int x = Int32.Parse(a.Text);
int y = Int32.Parse(b.Text);
Message.Text = mycls.Add( x, y).ToString() ;
O asncrona:
class TestCallback
{
public static void Main()
{
//Create AsyncCallback delegate for the BeginAdd method.
AsyncCallback objCallBack = new
AsyncCallback(TestCallback.FactorizeCallback1);
// Begin the Asynchronous call to the Web Service
Calc1 objCalcService = new Calc1();
Juan Francisco Adame Lorite

IAsyncResult objAsyncResult = objCalcService.BeginAdd(5, 5, objCallBack,

objCalcService);
... // Other tasks
// Keep track how long it takes to complete the async call
while (objAsyncResult.IsCompleted == false)
{
... // Task when finalized
}
}
// Callback function invoked by the proxy class when the asynchronous
operation completes
public static void FactorizeCallback1(IAsyncResult objAsyncResult)
{
// Use the AsyncState property to get the Web Service proxy object
Calc1 objCalcService = (Calc1) objAsyncResult.AsyncState;
// Get the completed results.
int results = objCalcService.EndAdd(objAsyncResult);
}
}
Se comprueba que la plataforma no slo est orientada a los servicios Web,
sino que adems el entorno de desarrollo permite un despliegue muy rpido de
estos servicios incrementando la productividad en estas tareas.
Ms informacin en la pgina:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconwebservicesoverview.asp.

Aplicaciones ASP.NET
Las aplicaciones Web tambin han sufrido un gran cambio. Hay muchas
diferencias entre el lenguaje de scripting ASP antiguo y el moderno ASP.NET.
Las aplicaciones ASP.NET se pueden implementar en cualquier lenguaje de la
plataforma .NET y hacer uso de toda la biblioteca .NET FrameWork Class Library.
El nivel de presentacin se separa del funcional, cada uno se implementa en
un archivo distinto. Se puede trabajar diseo y funcionalidad de forma separada. El
modelo de interaccin de la GUI es idntico al modelo de eventos y delegados de
los formularios Windows, lo que da mucha ms flexibilidad y funcionalidad a las
aplicaciones Web. El cdigo client-side y server-side se desarrolla en el mismo
entorno.
El cdigo no es un script interpretado es cdigo binario compilado de la
misma manera que se ejecuta el resto de cdigo en la plataforma .NET como se
explic al comienzo del trabajo. Esto da mucha ms eficiencia y rapidez a servicios
Web y aplicaciones Web.
Ms informacin en la pgina:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconcreatingaspwebapplications.asp.

ADO.NET
Es el nuevo interfaz de acceso a fuentes de datos, posee cuatro
implementaciones del tipo abstracto de base:
OLEDB: para ficheros CSV, Excel, Access,
ODBC: para bases de datos con conectividad ODBC
SQL: para SQL Server versin 7 o mayor
Oracle: para Oracle Database versin 8 o mayor
As mismo, se conserva el escenario clsico conectado y se aade uno
nuevo, el escenario no conectado.
Ms informacin sobre ADO.NET en:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconaccessingdatawithadonet.asp.
Juan Francisco Adame Lorite

ADO.NET: Escenario conectado

Es el escenario clsico de acceso a las fuentes de datos. Primero se
establece una conexin, se ejecuta un comando SQL y se leen los datos devueltos
con un reader.
En este escenario las relaciones entre elementos y las restricciones e
integridad se comprueban en la fuente de datos. Cuando se produce un error, ste
se propaga hasta la aplicacin cliente, siendo este proceso ms lento.
El interfaz es el interfaz de la fuente de datos, hacemos peticiones en el
lenguaje de la fuente de datos. Un cambio de fuente de datos podra provocar un
cambio en todas las consultas de la aplicacin cliente.
Se requiere una conexin contina con la fuente de datos, situacin que no
es posible en muchos casos como en los dispositivos porttiles.

El siguiente es un ejemplo de cdigo:

public void ReadMyData(string myConnString) {
string mySelectQuery = "SELECT OrderID, CustomerID FROM Orders";
SqlConnection myConnection = new SqlConnection(myConnString);
SqlCommand myCommand = new SqlCommand(mySelectQuery,myConnection);
myConnection.Open();
SqlDataReader myReader;
myReader = myCommand.ExecuteReader();
// Always call Read before accessing data.
while (myReader.Read()) {
Console.WriteLine(myReader.GetInt32(0)+myReader.GetString(1));
}
// Always call Close when done reading.
myReader.Close();
// Close the connection when done with it.
myConnection.Close();
}

ADO.NET: Escenario no conectado

El escenario no conectado es apropiado para las situaciones en las que el
cliente no est conectado directamente, o las solicitudes son espordicas y no
podemos copar el recurso de la conexin continuamente.
La idea de este escenario es modelar en la aplicacin parte de la base de
datos, trabajar sobre este modelo y actualizar la base de datos con los cambios al
finalizar.
El objeto que modela la base de datos, sus tablas, sus relaciones entre
tablas y restricciones de las columnas es el DataSet. Su estructura se define con un
documento XML que define todos estos elementos.
El elemento que rellena el DataSet y actualiza los cambios sufridos en l es
el DataAdapter. El DataAdapter posee los mtodos Select para rellenar el DataSet
consultando datos a la fuente de datos y los mtodos Update, Insert y Delete para
reflejar los cambios sufridos en el DataSet en la fuente de datos.
Inicialmente deberemos rellenar el DataSet con las filas y tablas que
deseemos, el mtodo Select del DataAdapter elige que filas y tablas se cargan. A
continuacin podemos trabajar con las filas y tablas del DataSet sin necesidad de
que haya conexin con la fuente de datos. El DataSet comprueba que las
restricciones de tablas (relaciones) y columnas (constraints) definidas en su
esquema se conserven. Cuando finalicemos, las filas creadas estarn marcadas
como tales y se actualizarn en la fuente de datos mediante el mtodo Insert, las
Juan Francisco Adame Lorite

modificadas con el mtodo Update y las borradas con el mtodo Delete del
DataAdapter.
Existe un problema aadido en este escenario no existente en el anterior,
durante el tiempo que no hay conexin se producen actualizaciones en la fuente de
datos que pueden provocar incoherencias al actualizar el DataSet. Esas
incoherencias se detectan y pueden ser subsanadas.

El siguiente es un ejemplo de cdigo:

string cString = "user id=sa;password=;initial catalog=northwind;data
source=MyComputerName\\NetSDK;Connect Timeout=5";
SqlConnection myConnection = new SqlConnection(cString);
// Create a SqlDataAdapter.
SqlDataAdapter myAdapter = new SqlDataAdapter();
myAdapter.TableMappings.Add(TSuppliers", "Suppliers");
myConnection.Open();
SqlCommand myCommand = new SqlCommand("SELECT * FROM TSuppliers",myConnection);
myCommand.CommandType = CommandType.Text;
myAdapter.SelectCommand = myCommand;
ds = new DataSet("Customers");
myAdapter.Fill(ds);
// Create a second Adapter and Command.
SqlDataAdapter adpProducts = new SqlDataAdapter();
adpProducts.TableMappings.Add(TProducts", "Products");
SqlCommand cmdProducts = new SqlCommand("SELECT * FROM TProducts", myConnection);
adpProducts.SelectCommand = cmdProducts;
adpProducts.Fill(ds);
myConnection.Close();
// Create a FK relation between both tables
System.Data.DataRelation dr;
System.Data.DataColumn dc1;
System.Data.DataColumn dc2;
// Get the parent and child columns of the two tables.
dc1 = ds.Tables["Suppliers"].Columns["SupplierID"];
dc2 = ds.Tables["Products"].Columns["SupplierID"];
dr = new System.Data.DataRelation("suppliers2products", dc1, dc2);
ds.Relations.Add(dr);
// Get supplier from suppliers' table
DataView suppliers = new DataView();
suppliers.Table = ds.Tables["Suppliers"];
suppliers.RowFilter = "Name = 'The supplier'";
int ID = suppliers[0]["SupplierID"];
// Create a new row in products' table
DataRow fila = ds.Tables["Products"].NewRow();
fila["SupplierID"]=ID;
...
fila["Name"]=@"products' name";
ds.Tables["Products"].Rows.Add(fila);
// Update Changes
DataSet changes = ds.GetChanges();
myAdapter.Update(changes);
adpProducts.Update(changes);
// Check conflicts and errors
if (ds.HasErrors){
DataRow[] errores = ds.Tables["Products"].GetErrors();
... // Fixing conflicts
} else ds.AcceptChanges();

Referencias
Programming C#, 3 edicin; Jessy Liberty; OReily
C# in a Nutshell, marzo 2002; Peter Drayton, Ben Albahari
& Ted Neward; OReily
Juan Francisco Adame Lorite

.NET Framework Essentials; junio 2001, Thuan Thai & Hoang Lam,
OReily
Plataforma .NET
http://msdn.microsoft.com/library/default.asp?url=/library/en
-us/cpguide/html/cpconinsidenetframework.asp
C#
http://www.codeproject.com
http://msdn.microsoft.com/library/default.asp?url=/library/en
-us/csref/html/vcoriCSharpTutorials.asp
ASP.NET
http://www.asp.net
http://www.4guysfromrolla.com/
http://411asp.net/
Servidores gratuitos ASP.NET, para probar:
http://europe.webmatrixhosting.net/
http://dotnetplayground.com/
Y las especficas de cada captulo
Juan Francisco Adame Lorite