Crear aplicaciones

ASP.NET seguras
Autenticacin, autorizacin y
comunicacin segura
Captulo 3 - Autenticacin
y autorizacin
J.D. Meier, Alex Mackman, Michael Dunner y Srinath Vasireddy
Microsoft Corporation
Octubre de !!
Consulte la "#$ina de entrada como punto de partida y para obtener una descripci%n
completa del documento Crear aplicaciones ASP.NET seguras.
Resumen
&ste cap'tulo contiene instrucciones para ayudarle a desarrollar una estrate$ia de
autori(aci%n adecuada a su escenario de aplicaciones espec'fico. )e ayudar# a
seleccionar la t*cnica de autenticaci%n y autori(aci%n m#s apropiada y a aplicarla en
los puntos adecuados de la aplicaci%n.
Contenido
Dise+ar una estrate$ia de autenticaci%n y autori(aci%n
&nfo,ues de autori(aci%n
-ransmitir la identidad
Autori(aci%n basada en funciones
Seleccionar un mecanismo de autenticaci%n
Conclusi%n
&l dise+o de una estrate$ia de autenticaci%n y autori(aci%n para aplicaciones .eb
distribuidas constituye un /erdadero desaf'o. Afortunadamente, el disponer de un
dise+o adecuado de la autenticaci%n y la autori(aci%n durante las primeras fases del
desarrollo de la aplicaci%n ayuda a miti$ar muchos de los peores ries$os de
se$uridad.
&ste cap'tulo le ayudar# a dise+ar una estrate$ia de autori(aci%n adecuada para la
aplicaci%n y a responder a las si$uientes pre$untas cla/e0
1 2D%nde debo reali(ar la autori(aci%n y ,u* mecanismos debo utili(ar3
1 24u* mecanismo de autenticaci%n debo utili(ar3
1 2Debo utili(ar el ser/icio de directorios de Acti/e Directory5 para la
autenticaci%n o /alidar las credenciales con un almac*n de datos
personali(ado3
1 2Cu#les son las implicaciones y las consideraciones de dise+o de las
plataformas hetero$*neas y homo$*neas3
1 2C%mo debo representar en la aplicaci%n a los usuarios ,ue no utili(an el
sistema operati/o Microsoft5 .indo6s53
1 2C%mo debo transmitir la identidad de usuarios por los ni/eles de la
aplicaci%n3 2Cu#ndo debo utili(ar la suplantaci%n o dele$aci%n del sistema
operati/o3

Cuando considere la autori(aci%n, deber# tambi*n considerar la autenticaci%n.
Deben considerarse simult#neamente los dos procesos por dos ra(ones0
1 &n primer lu$ar, cual,uier directi/a de autori(aci%n coherente re,uiere la
existencia de usuarios autenticados.
1 &n se$undo lu$ar, el modo de autenticaci%n de los usuarios 7y sobre todo el
modo de representaci%n de la identidad de usuarios autenticados en la
aplicaci%n8 determina los $uardianes de los ,ue podr# disponer.
Al$unos $uardianes, como la autori(aci%n de archi/os de AS".9&-, las
funciones de la aplicaci%n de Ser/icios &mpresariales 7COM:8 y las AC) de
.indo6s, re,uieren una identidad de .indo6s autenticada, en forma de
ob;eto WindowsIdentity ,ue encapsula un testi$o de acceso de .indo6s, el
cual define el contexto de se$uridad del llamador. Otros $uardianes, como la
autori(aci%n de direcciones <=) de AS".9&- y las funciones de .9&- no la
re,uieren. =e,uieren solamente una identidad autenticada, ,ue no tiene por
,u* estar representada for(osamente por un testi$o de acceso de .indo6s.

Disear una estrategia de autenticacin y
autorizacin
)os si$uientes pasos definen un proceso ,ue le ayudar# a desarrollar una estrate$ia
de autenticaci%n y autori(aci%n para la aplicaci%n.
>. ?dentificar los recursos
. Seleccionar una estrate$ia de autori(aci%n
@. Seleccionar las identidades utili(adas para el acceso a recursos
A. Considerar la transmisi%n de la identidad
B. Seleccionar un enfo,ue de autenticaci%n
C. Decidir c%mo transmitir la identidad

Identificar los recursos
?dentifi,ue los recursos ,ue la aplicaci%n necesita exponer a los clientes. &ntre los
recursos, suelen fi$urar0
1 =ecursos de ser/idores .eb, como las p#$inas .eb, los ser/icios .eb y los
recursos est#ticos 7p#$inas D-M) e im#$enes8
1 =ecursos de bases de datos, como los datos por usuario o los datos $enerales
de la aplicaci%n
1 =ecursos de red, como los recursos de sistemas de archi/os remotos y los
datos de almacenes de directorios como Acti/e Directory.

-ambi*n deber# identificar los recursos del sistema a los ,ue necesita tener acceso
la aplicaci%n. &stos recursos se contraponen a los recursos ,ue se exponen a los
clientes. &ntre los recursos del sistema, fi$uran el re$istro, los re$istros de sucesos y
los archi/os de confi$uraci%n.
Seleccionar una estrategia de autorizacin
)as dos estrate$ias b#sicas de autori(aci%n son0
1 Basada en funciones. &l acceso a las operaciones 7normalmente m*todos8
se prote$e en funci%n de la pertenencia a funciones del llamador. )as
funciones sir/en para di/idir la base de usuarios de la aplicaci%n en con;untos
de usuarios ,ue comparten los mismos pri/ile$ios de se$uridad en la
aplicaci%n, como por e;emplo, Directi/os superiores, Directores y &mpleados.
)os usuarios se asi$nan a funciones y, si el usuario est# autori(ado a reali(ar
la operaci%n solicitada, la aplicaci%n utili(a identidades fi;as para obtener
acceso a los recursos. &stas identidades tienen la confian(a de los
administradores de recursos respecti/os 7por e;emplo, las bases de datos, el
sistema de archi/os, etc.8.
1 Basada en recursos. )os recursos indi/iduales se prote$en mediante listas
de control de acceso 7AC)8 de .indo6s. )a aplicaci%n suplanta al llamador
antes de obtener acceso a los recursos, lo ,ue permite al sistema operati/o
reali(ar controles est#ndar de acceso. -odo acceso a recursos se reali(a
mediante el contexto de se$uridad del llamador ori$inal. &ste enfo,ue de
suplantaci%n tiene un fuerte impacto en la escalabilidad de la aplicaci%n,
puesto ,ue no permite utili(ar la a$rupaci%n de conexiones de forma efica( en
el ni/el medio de la aplicaci%n.

&n la $ran mayor'a de las aplicaciones .eb .9&- para las ,ue es primordial la
escalabilidad, el enfo,ue basado en funciones de la autori(aci%n suele ser la me;or
opci%n. "ara determinadas aplicaciones de intranet de menor escala en las ,ue el
contenido para usuarios se distribuye a partir de recursos 7como archi/os8 ,ue se
pueden prote$er del acceso de usuarios indi/iduales mediante AC) de .indo6s,
podr'a resultar m#s adecuado utili(ar un enfo,ue basado en recursos.
&l patr%n recomendado y m#s habitual para la autori(aci%n basada en funciones es0
1 Autenticar los usuarios en la aplicaci%n .eb cliente
1 Asi$nar los usuarios a funciones
1 Autori(ar el acceso a operaciones 7no directamente a los recursos8 en funci%n
de la pertenencia a funciones
1 Obtener acceso a los recursos de ser/idor necesarios 7para admitir las
operaciones solicitadas y autori(adas8 mediante identidades fi;as de ser/icio.
)os administradores de recursos de ser/idor 7como las bases de datos8
confan en la aplicaci%n para ,ue autorice llamadores y est#n dispuestos a
conceder permisos a la identidad o identidades de ser/icio de confian(a.
"or e;emplo, un administrador de bases de datos podr'a conceder permisos de
acceso exclusi/amente a una aplicaci%n de ==.DD. espec'fica 7y no a usuarios
indi/iduales8.

Ms informacin
1 "ara obtener m#s informaci%n acerca de los dos enfo,ues de autori(aci%n
contrapuestos, consulte E&nfo,ues de autori(aci%nE m#s adelante en este
cap'tulo.
1 "ara obtener m#s informaci%n acerca de la autori(aci%n basada en funciones y
los distintos tipos de funciones ,ue se pueden utili(ar, consulte EAutori(aci%n
basada en funcionesE m#s adelante en este cap'tulo.

Seleccionar las identidades utilizadas para el acceso a
recursos
=esponda a la pre$unta0 2,ui*n /a a tener acceso a los recursos3
&li;a la identidad o identidades ,ue se deben utili(ar para obtener acceso a los
recursos en los ni/eles de la aplicaci%n. &sto incluye recursos a los ,ue se obtiene
acceso desde aplicaciones basadas en .eb y, opcionalmente, componentes de
Ser/icios .eb, Ser/icios &mpresariales y .9&- =emotin$. &n todos los casos, la
identidad utili(ada para el acceso a los recursos puede ser0
1 a identidad del llamador original. Asume un modelo de
suplantaci%nFdele$aci%n en el ,ue la identidad del llamador ori$inal puede
obtenerse y transmitirse por cada capa del sistema. &l factor de dele$aci%n
constituye un criterio cla/e a la hora de determinar el mecanismo de
autenticaci%n.
1 a identidad del proceso. Gste es el caso predeterminado 7sin suplantaci%n
espec'fica8. &l acceso a los recursos locales y las llamadas a capas inferiores
se reali(an con la identidad del proceso actual. )a /iabilidad de este enfo,ue
depende del l'mite ,ue se traspasa, puesto ,ue el sistema de destino debe
reconocer la identidad del proceso.

De este modo, las llamadas se reali(an de una de las si$uientes formas0
1 &n el mismo dominio de se$uridad de .indo6s
1 &n dominios distintos de se$uridad de .indo6s 7mediante cuentas de
confian(a y de dominio, o nombres de usuario y contrase+as duplicados
cuando no existe una relaci%n de confian(a8

1 Cuenta de ser!icio. &ste enfo,ue utili(a una cuenta 7fi;a8 de ser/icio. "or
e;emplo0
1 "ara el acceso a bases de datos, podr'a tratarse de un nombre de usuario
y una contrase+a fi;os de S4) presentados por el componente ,ue se
conecta a la base de datos.
1 Cuando se re,uiera una identidad fi;a de .indo6s, deber# utili(ar una
aplicaci%n de ser/idor de Ser/icios &mpresariales.

1 Identidad personalizada. Cuando no dispon$a de cuentas de .indo6s,
podr# crear sus propias identidades 7mediante implementaciones de I"rincipal
e IIdentity8 ,ue pueden contener informaci%n relacionada con su propio
contexto de se$uridad. "odr'a incluir, por e;emplo, listas de funciones,
identificadores Hnicos o cual,uier otro tipo de informaci%n personali(ada.
Al implementar su identidad personali(ada con los tipos I"rincipal e IIdentity
y situarlos en el contexto .eb actual 7mediante #ttpConte$t%&ser8, dispondr#
inmediatamente de $uardianes inte$rados, como las funciones de .9&- y las
peticiones "rincipal"ermission.

Considerar la transmisin de la identidad
"ara admitir la autori(aci%n por usuario, la auditor'a y la recuperaci%n de datos por
usuario, es posible ,ue necesite transmitir la identidad del llamador ori$inal por
/arios ni/eles de la aplicaci%n y /arios l'mites de e,uipos. "or e;emplo, si un
administrador de recursos de ser/idor necesita reali(ar la autori(aci%n por llamador,
deber# pasarse la identidad del llamador al administrador de recursos.
Determine las identidades ,ue necesita pasar por la aplicaci%n en funci%n de los
re,uisitos de autori(aci%n del administrador de recursos y los re,uisitos de auditor'a
del sistema.
Seleccionar un enfo'ue de autenticacin
Dos de los factores cla/e ,ue influencian la selecci%n del enfo,ue de autenticaci%n
son, en primer lu$ar, la naturale(a de la base de usuarios de la aplicaci%n 7los tipos
de exploradores ,ue utili(an y si tienen cuentas de .indo6s8 y, en se$undo lu$ar, los
re,uisitos de suplantaci%nFdele$aci%n y de auditor'a de la aplicaci%n.
Ms informacin
"ara obtener informaci%n m#s detallada ,ue le ayudar# a seleccionar un mecanismo
de autenticaci%n para su aplicaci%n, consulte ESeleccionar un mecanismo de
autenticaci%nE m#s adelante en este cap'tulo.
Decidir cmo transmitir la identidad
"uede transmitir la identidad 7para proporcionar el contexto de se$uridad8 en la
aplicaci%n o transmitir la identidad y el contexto de se$uridad en el sistema operati/o.
"ara transmitir la identidad en la aplicaci%n, deber# utili(ar par#metros de m*todos y
de procedimientos almacenados. )a transmisi%n de la identidad en la aplicaci%n
admite0
1 )a recuperaci%n de datos por usuario mediante par#metros de consulta de
confian(a
SELECT x,y FROM SomeTable WHERE username="bob"
1 )a auditor'a personali(ada en cual,uier ni/el de la aplicaci%n

)a transmisi%n de la identidad en el sistema operati/o admite0
1 )a auditor'a de plataformas 7por e;emplo, la auditor'a de .indo6s y de S4)
Ser/er8
1 )a autori(aci%n por usuario basada en identidades de .indo6s

"ara transmitir la identidad en el sistema operati/o, puede utili(ar el modelo de
suplantaci%nFdele$aci%n. &n al$unas circunstancias, puede utili(ar la dele$aci%n
Ierberos, mientras ,ue en otras 7en las ,ue ,ui(#s el entorno no admite Ierberos8,
es posible ,ue necesite utili(ar otros enfo,ues, como el uso de la autenticaci%n
b#sica. Con la autenticaci%n b#sica, las credenciales del usuario se ponen a
disposici%n de la aplicaci%n de ser/idor y pueden utili(arse para obtener acceso a
recursos de red de capas inferiores.
Ms informacin
"ara obtener m#s informaci%n acerca de c%mo transmitir la identidad y obtener un
testi$o de suplantaci%n con credenciales de red 7es decir, compatible con la
dele$aci%n8, consulte E-ransmitir la identidadE m#s adelante en este cap'tulo.
(nfo'ues de autorizacin
&xisten dos enfo,ues b#sicos de la autori(aci%n0
1 Basada en funciones. )os usuarios se di/iden en funciones l%$icas definidas
por la aplicaci%n. )os miembros de una funci%n determinada comparten los
mismos pri/ile$ios en la aplicaci%n. &l acceso a las operaciones 7normalmente
llamadas a m*todos8 se autori(a en funci%n de la pertenencia a funciones del
llamador.
&l acceso a los recursos se reali(a con identidades fi;as 7como la identidad del
proceso de una aplicaci%n .eb o de un ser/icio .eb8. )os administradores de
recursos conf'an en la aplicaci%n para ,ue autorice correctamente a los
usuarios y autori(an la identidad de confianza.
1 Basada en recursos. )os recursos indi/iduales se prote$en mediante AC) de
.indo6s. )a AC) determina los usuarios a los ,ue se permite el acceso al
recurso ;unto con los tipos de operaci%n ,ue puede reali(ar cada usuario 7leer,
escribir, eliminar, etc.8.
&l acceso a los recursos se lle/a a cabo con la identidad del llamador ori$inal
7mediante la suplantaci%n8.

Basada en funciones
Con un enfo,ue de la se$uridad basado en funciones 7u operaciones8, el acceso a
las operaciones 7y no a los recursos de ser/idor8 se autori(a se$Hn la pertenencia a
funciones del llamador. )as funciones 7anali(adas y definidas al dise+ar la aplicaci%n8
se utili(an como contenedores l%$icos ,ue a$rupan usuarios ,ue comparten los
mismos pri/ile$ios de se$uridad 7o capacidades8 en la aplicaci%n. )os usuarios se
asi$nan a funciones en la aplicaci%n y la pertenencia a funciones sir/e para controlar
el acceso a operaciones 7m*todos8 espec'ficas expuestas por la aplicaci%n.
&l lu$ar de la aplicaci%n en el ,ue se produce la asi$naci%n de funciones es un
criterio cla/e de dise+o, a saber0
1 "or un lado, la asi$naci%n de funciones podr'a reali(arse en un administrador
de recursos de ser/idor, como una base de datos. &sto re,uiere la transmisi%n
del contexto de se$uridad del llamador ori$inal por los ni/eles de la aplicaci%n
hasta la base de datos de ser/idor.
1 "or otro lado, la asi$naci%n de funciones podr'a reali(arse en la aplicaci%n
.eb cliente. Con este enfo,ue, el acceso a los administradores de recursos de
capas inferiores se reali(a con identidades fi;as ,ue autori(a y en las ,ue est#
dispuesto a confiar cada administrador de recursos.
1 <na tercera opci%n consistir'a en reali(ar la asi$naci%n de funciones entre los
ni/eles de cliente y de ser/idor, como por e;emplo, en una aplicaci%n de
Ser/icios &mpresariales de ni/el medio.

&n las aplicaciones .eb de /arios ni/eles, el uso de identidades de confian(a para
obtener acceso a los administradores de recursos de ser/idor ofrece mayores
oportunidades para la escalabilidad de la aplicaci%n 7$racias a la a$rupaci%n de
conexiones8. Adem#s, el uso de identidades de confian(a miti$a la necesidad de
transmitir el contexto de se$uridad del llamador ori$inal en el sistema operati/o, lo
,ue puede resultar dif'cil 7o casi imposible en determinados escenarios8 de
conse$uir.
Basada en recursos
&l enfo,ue de autori(aci%n basado en recursos depende de AC) de .indo6s y de
los mecanismos de control de acceso subyacentes del sistema operati/o. )a
aplicaci%n suplanta al llamador y de;a ,ue el sistema operati/o, ;unto con
determinados administradores de recursos 7el sistema de archi/os, las bases de
datos, etc.8, realice los controles de acceso.
&ste enfo,ue suele ser m#s adecuado para aplicaciones ,ue proporcionan acceso a
recursos ,ue se pueden prote$er de forma independiente con AC) de .indo6s,
como por e;emplo, los archi/os. <n e;emplo ser'a una aplicaci%n J-" o una
aplicaci%n .eb controlada por datos. &l enfo,ue empie(a a fallar cuando el recurso
solicitado est# compuesto por datos ,ue se deben obtener y consolidar desde /arios
or'$enes distintos, como por e;emplo, /arias bases de datos, tablas de base de
datos, aplicaciones externas o ser/icios .eb.
&l enfo,ue basado en recursos depende tambi*n de la transmisi%n del contexto de
se$uridad del llamador ori$inal por la aplicaci%n hasta los administradores de
recursos de ser/idor. &sta transmisi%n puede re,uerir una confi$uraci%n comple;a y
disminuye considerablemente la capacidad de una aplicaci%n de /arios ni/eles de
extenderse a muchos usuarios, puesto ,ue impide el uso efica( de la a$rupaci%n 7por
e;emplo, la a$rupaci%n de conexiones de bases de datos8 en el ni/el medio de la
aplicaci%n.
Modelos de acceso a recursos
)os dos enfo,ues contrapuestos de la autori(aci%n pueden /erse en los dos modelos
de se$uridad de acceso a recursos m#s habituales utili(ados por aplicaciones
.eb .9&- 7y aplicaciones de /arios ni/eles distribuidas en $eneral8. Se trata de0
1 &l modelo de subsistemas de confian(a
1 &l modelo de suplantaci%nFdele$aci%n

Cada modelo tiene sus /enta;as y des/enta;as, tanto desde el punto de /ista de la
se$uridad como de la escalabilidad. &stos modelos se describen en las si$uientes
secciones.
(l modelo de su)sistemas de confianza
&n este modelo, el ser/icio de ni/el medio utili(a una identidad fi;a para obtener
acceso a ser/icios y recursos de ni/eles inferiores. &l contexto de se$uridad del
llamador ori$inal no se transmite por el ser/icio en el sistema operati/o, aun,ue la
aplicaci%n puede decidir reali(ar la transmisi%n de la identidad del llamador ori$inal
en la aplicaci%n. "uede ,ue necesite hacer esto Hltimo para admitir los re,uisitos de
auditor'a del ser/idor o el acceso a datos y la autori(aci%n por usuario.
&l nombre del modelo se deri/a del hecho de ,ue el ser/icio de ni/el inferior 7,ui(#s
una base de datos8 conf'a en el ser/icio de ni/el superior para la autori(aci%n de
llamadores. &ste modelo se muestra en la ilustraci%n @.>. "reste especial atenci%n al
l'mite de confian(a. &n este e;emplo, la base de datos confa en el ni/el medio para
,ue autorice llamadores y permita solamente a los llamadores autori(ados el acceso
a la base de datos con la identidad de confian(a.
{nsert !gure" C#$3 - Truste%Su&System.gi'(
?lustraci%n @.>
El modelo de subsistemas de confanza
Gste es el patr%n de acceso a los recursos del modelo de subsistemas de confian(a0
1 Autenticar los usuarios
1 Asi$nar los usuarios a funciones
1 =eali(ar la autori(aci%n se$Hn la pertenencia a funciones
1 Obtener acceso al administrador de recursos de ni/el inferior con una
identidad fi;a de confian(a

Identidades fi*as
)a identidad fi;a ,ue se utili(a para obtener acceso a sistemas y administradores de
recursos de ni/eles inferiores suele proporcionarla una cuenta de .indo6s
preconfi$urada, ,ue se denomina cuenta de ser/icio. Si se trata de un administrador
de recursos de Microsoft S4) Ser/erK, esto implica la autenticaci%n de .indo6s en
S4) Ser/er.
Como alternati/a, al$unas aplicaciones utili(an una cuenta desi$nada de S4)
7especificada por un nombre de usuario y una contrase+a en una cadena de
conexi%n8 para obtener acceso a S4) Ser/er. &n este escenario, la base de datos
deber# estar confi$urada para utili(ar la autenticaci%n de S4).
"ara obtener m#s informaci%n acerca de las /enta;as de la autenticaci%n de
.indo6s y de S4) a la hora de establecer la comunicaci%n con S4) Ser/er, consulte
el cap'tulo >, ESe$uridad del acceso a datosE.
&tilizar !arias identidades de confianza
&s posible ,ue al$unos administradores de recursos necesiten poder lle/ar a cabo
una autori(aci%n m#s espec'fica basada en la pertenencia a funciones del llamador.
"or e;emplo, podr'a tener dos $rupos de usuarios0 uno ,ue necesita obtener
autori(aci%n para reali(ar operaciones de lectura y escritura y otro ,ue necesita
autori(aci%n para operaciones s%lo de lectura.
Considere el si$uiente enfo,ue con S4) Ser/er0
1 Cree dos cuentas de .indo6s0 una para operaciones de lectura y otra para
operaciones de lectura y escritura.
De forma m#s $eneral, tendr# cuentas independientes para representar
funciones espec'ficas de aplicaciones. "or e;emplo, es posible ,ue desee
utili(ar una cuenta para usuarios de ?nternet y otra para operadores o
administradores internos.
1 Asi$ne cada cuenta a una funci%n de base de datos definida por el usuario de
S4) Ser/er y defina los permisos de base de datos necesarios para cada
funci%n.
1 Asi$ne los usuarios a funciones de la aplicaci%n y utilice la pertenencia a
funciones para determinar la cuenta ,ue se /a a suplantar antes de establecer
la conexi%n con la base de datos.

&ste enfo,ue se muestra en la ilustraci%n @..
{nsert !gure" C#$3 ) Truste% Su&system ) *ultiple %entities.gi'(
?lustraci%n @.
Utilizar varias identidades para obtener acceso a una base de datos con el fn de
admitir una autorizacin ms especfca
(l modelo de suplantacin+delegacin
&n este modelo, un ser/icio o componente 7normalmente ubicado en la capa l%$ica
de ser/icios empresariales8 suplanta la identidad del cliente 7mediante la
suplantaci%n del sistema operati/o8 antes de obtener acceso al si$uiente ser/icio de
ni/el inferior. Si el si$uiente ser/icio est# en el mismo e,uipo, basta con la
suplantaci%n. Se re,uiere la dele$aci%n cuando el ser/icio de ni/el inferior est#
ubicado en un e,uipo remoto.
Como consecuencia de la dele$aci%n, el contexto de se$uridad utili(ado para el
acceso al recurso de ni/el inferior es el del cliente. &ste modelo suele utili(arse por
dos ra(ones0
1 "ermite al ser/icio de ni/el inferior reali(ar la autori(aci%n por llamador con la
identidad del llamador ori$inal.
1 "ermite al ser/icio de ni/el inferior utili(ar caracter'sticas de auditor'a del
sistema operati/o.

&n concreto, con esta t*cnica, un componente de la aplicaci%n de Ser/icios
&mpresariales del ni/el medio podr'a suplantar al llamador antes de obtener acceso
a una base de datos. &l acceso a la base de datos se reali(a mediante una conexi%n
de base de datos /inculada al contexto de se$uridad del llamador ori$inal. &n este
modelo, la base de datos autentica cada uno de los llamadores y toma decisiones de
autori(aci%n en funci%n de los permisos asi$nados a la identidad del llamador 7o la
pertenencia a $rupos de .indo6s del llamador8. &l modelo de
suplantaci%nFdele$aci%n se muestra en la ilustraci%n @.@.
{nsert !gure" C#$3 +riginalCaller*o%el.gi'(
?lustraci%n @.@
El modelo de suplantacin/delegacin
Seleccionar un modelo de acceso a recursos
&l modelo de subsistemas de confian(a se utili(a en la $ran mayor'a de las
aplicaciones de ?nternet y de intranet a $ran escala, principalmente por ra(ones de
escalabilidad. &l modelo de suplantaci%n suele utili(arse en aplicaciones a menor
escala en las ,ue la escalabilidad no es el factor principal y en aplicaciones en las
,ue la auditor'a 7por ra(ones de no recha(o8 tiene una importancia primordial.
,enta*as del modelo de suplantacin+delegacin
)a principal /enta;a del modelo de suplantaci%nFdele$acion es la auditor'a 7cerca de
los datos8. )a auditor'a permite a los administradores reali(ar un se$uimiento de los
usuarios ,ue han intentado obtener acceso a determinados recursos. &n $eneral, la
auditor'a se considera m#s fidedi$na si se $enera en el momento exacto en el ,ue se
produ;o el acceso al recurso y con las mismas rutinas ,ue obtienen acceso al mismo.
&l modelo de suplantaci%nFdele$aci%n satisface este re,uisito, puesto ,ue mantiene
el contexto de se$uridad del usuario para el acceso a recursos de ni/eles inferiores.
&sto permite al sistema de ser/idor reali(ar un re$istro del usuario y del acceso
solicitado de forma confiable.
Des!enta*as del modelo de suplantacin+delegacin
&ntre las des/enta;as relacionadas con el modelo de suplantaci%nFdele$aci%n,
fi$uran0
1 "ro)lemas tecnolgicos. )a mayor'a de los pro/eedores de ser/icios de
se$uridad no admiten la dele$aci%n, a excepci%n de Ierberos.
)os procesos ,ue lle/an a cabo la suplantaci%n re,uieren mayores pri/ile$ios
7en concreto, el pri/ile$io Actuar como parte del sistema operativo8. 7&sta
restricci%n se aplica a .indo6s !!!, pero no se aplicar# a .indo6s Ser/er
!!@8.
1 (scala)ilidad. &l modelo de suplantaci%nFdele$aci%n impide el uso efica( de
la a$rupaci%n de conexiones de bases de datos, puesto ,ue el acceso a bases
de datos se reali(a mediante conexiones /inculadas a los contextos de
se$uridad indi/iduales de los llamadores ori$inales. &sto limita
considerablemente la capacidad de la aplicaci%n de extenderse a muchos
usuarios.
1 -umento de las tareas de administracin. )as AC) de recursos de ser/idor
necesitan mantenerse de forma ,ue a cada usuario se le conceda el ni/el de
acceso adecuado. Cuando aumenta el nHmero de recursos de ser/idor 7y
tambi*n el nHmero de usuarios8, se produce un aumento considerable de las
tareas de administraci%n necesarias para las AC).
,enta*as del modelo de su)sistemas de confianza
&l modelo de subsistemas de confian(a ofrece las si$uientes /enta;as0
1 (scala)ilidad. &l modelo de subsistemas de confian(a admite la a$rupaci%n
de conexiones, un re,uisito esencial para la escalabilidad de la aplicaci%n. )a
a$rupaci%n de conexiones permite a /arios clientes reutili(ar conexiones
a$rupadas disponibles. Junciona con este modelo por,ue todos los accesos a
los recursos de ser/idor utili(an el contexto de se$uridad de la cuenta de
ser/icio, independientemente de la identidad del llamador.
1 Minimiza la administracin de -C de ser!idor. S%lo tiene acceso a los
recursos de ser/idor 7por e;emplo, bases de datos8 la cuenta de ser/icio. )as
AC) est#n confi$uradas para esta sola identidad.
1 os usuarios no pueden o)tener acceso a datos directamente. &n el
modelo de subsistemas de confian(a, s%lo se concede acceso a los recursos
de ser/idor a la cuenta de ser/icio de ni/el medio. De este modo, los usuarios
no pueden obtener acceso a los datos de ser/idor directamente sin pasar
primero por la aplicaci%n 7y deben pasar por la autori(aci%n de la aplicaci%n8.

Des!enta*as del modelo de su)sistemas de confianza
&l modelo de subsistemas de confian(a tiene dos incon/enientes0
1 -uditor.a. "ara reali(ar la auditor'a del ser/idor, puede pasar expl'citamente
7en la aplicaci%n8 la identidad del llamador ori$inal al ser/idor y hacer ,ue se
lle/e a cabo la auditor'a en *l. -iene ,ue confiar en el ni/el medio y existe un
ries$o potencial de recha(o. Como alternati/a, puede $enerar una pista de
auditor'a en el ni/el medio y, a continuaci%n, establecer una correlaci%n entre
este ni/el y las pistas de auditor'a del ser/idor 7para lo ,ue debe ase$urarse
de ,ue est*n sincroni(ados los relo;es del ser/idor8.
1 Mayor riesgo de comprometer el ser!idor. &n el modelo de subsistemas de
confian(a, se concede al ser/icio de ni/el medio acceso $eneral a los recursos
de ser/idor. Como consecuencia, un ser/icio de ni/el medio comprometido
podr'a facilitar el acceso $lobal de un intruso a los recursos de ser/idor.

/ransmitir la identidad
)as aplicaciones distribuidas pueden di/idirse en /arios subsistemas se$uros. "or
e;emplo, una aplicaci%n .eb cliente, un ser/icio .eb de ni/el medio, un componente
remoto y una base de datos ser'an cuatro subsistemas de se$uridad distintos. Cada
uno de ellos lle/a a cabo la autenticaci%n y la autori(aci%n.
Deber# identificar los subsistemas ,ue deben transmitir la identidad del llamador 7y el
contexto de se$uridad correspondiente8 al si$uiente subsistema de ni/el inferior para
admitir la autori(aci%n con el llamador ori$inal.
Comparacin de la transmisin de identidad en la
aplicacin y en el sistema operati!o
&ntre las estrate$ias de transmisi%n de identidades, fi$uran el uso de caracter'sticas
de dele$aci%n del sistema operati/o y el paso de /ales o de credenciales en la
aplicaci%n. "or e;emplo0
1 "ara transmitir la identidad en la aplicaci%n, se suelen pasar credenciales 7o
/ales8 mediante ar$umentos de m*todos o par#metros de procedimientos
almacenados.
0ota1 los ob;etos 2eneric"rincipal con la identidad del llamador ori$inal no
se transmiten autom#ticamente por los procesos. &sto re,uerir'a c%di$o
personali(ado.
"uede pasar par#metros a procedimientos almacenados ,ue le permiten
recuperar y procesar datos espec'ficos de usuario. "or e;emplo0
SELECT CreditLimit From Table Where UserName="Bob"
&ste enfo,ue se denomina en ocasiones enfo,ue de parmetros de consulta
de confianza.
1 )a transmisi%n de la identidad en el sistema operati/o re,uiere una forma
a/an(ada de suplantaci%n ,ue se denomina dele$aci%n.

Suplantacin y delegacin
&n circunstancias normales, los subprocesos de una aplicaci%n de ser/idor se
e;ecutan con el contexto de se$uridad del proceso de ser/idor. )a sesi%n de inicio del
proceso mantiene los atributos ,ue componen el contexto de se$uridad del proceso,
y los expone el testi$o de acceso de .indo6s del proceso. -odos los accesos a
recursos locales y remotos se reali(an mediante el contexto de se$uridad del
proceso ,ue determina la cuenta de .indo6s utili(ada para e;ecutar el proceso de
ser/idor.
Suplantacin
Cuando se confi$ura una aplicaci%n de ser/idor para la suplantaci%n, se ad;unta un
testi$o de suplantaci%n al subproceso utili(ado para procesar una petici%n. &l testi$o
de suplantaci%n representa el contexto de se$uridad del llamador autenticado 7o
usuario an%nimo8. -odo acceso a recursos locales se reali(a mediante el testi$o de
suplantaci%n del subproceso, lo ,ue implica el uso del contexto de se$uridad del
llamador.
Delegacin
Si el subproceso de la aplicaci%n de ser/idor intenta obtener acceso a un recurso
remoto, se re,uiere la dele$aci%n. &n concreto, el testi$o del llamador suplantado
deber# tener credenciales de red. De lo contrario, el acceso a los recursos remotos
se reali(ar# como usuario an%nimo 7A<-DO=?-LMA9O9LMO<S )ONO98.
&xisten /arios factores ,ue determinan si se puede dele$ar o no un contexto de
se$uridad. )a tabla @.> muestra los distintos tipos de autenticaci%n de ??S e indica
para cada uno de ellos si se puede dele$ar el contexto de se$uridad del llamador
autenticado.
-abla @.>0 Tipos de autenticacin de IIS
-ipo de
autenticaci%n
Dele$aci%n 9otas
An%nima Depende Si la cuenta an%nima 7?<S=O&4<?"O de
forma predeterminada8 est# confi$urada
como cuenta local en ??S, no se puede
dele$ar excepto si el e,uipo local 7ser/idor
.eb8 y el e,uipo remoto tienen cuentas
locales id*nticas 7con nombres de usuario y
contrase+as id*nticos8.
Si la cuenta an%nima es una cuenta de
dominio, puede dele$arse.
P#sica S' Cuando se utili(a la autenticaci%n b#sica con
cuentas locales, puede dele$arse si las
cuentas locales de los e,uipos local y remoto
son id*nticas. )as cuentas de dominio
tambi*n se pueden dele$ar.
?mpl'cita 9o
?nte$rada en .indo6s Depende )a autenticaci%n inte$rada en .indo6s
puede utili(ar 9-)M o Ierberos 7en funci%n
de la /ersi%n del sistema operati/o del e,uipo
cliente y ser/idor8.
9-)M no admite la dele$aci%n.
Ierberos admite la dele$aci%n con un
entorno confi$urado de forma adecuada.
"ara obtener m#s informaci%n, consulte
EC%mo0 ?mplementar la dele$aci%n Ierberos
en .indo6s !!!E en la secci%n =eferencias
de esta $u'a.
Certificados de cliente Depende "uede dele$arse si se utili(a con la
asi$naci%n de certificados de ??S y se asi$na
el certificado a una cuenta local ,ue est#
duplicada en el e,uipo remoto o a una cuenta
de dominio.
&ste sistema es /#lido por,ue las
credenciales de la cuenta asi$nada se
almacenan en el ser/idor local y se utili(an
para crear una sesi%n de inicio interacti/a
7,ue tiene credenciales de red8.
)a asi$naci%n de certificados de Acti/e
Directory no admite la dele$aci%n.

Importante1 la dele$aci%n Ierberos en .indo6s !!! no est# restrin$ida. De este
modo, un usuario podr'a reali(ar /arios saltos de red en di/ersos e,uipos remotos.
"ara solucionar este ries$o de se$uridad potencial, deber# limitar el #mbito del
alcance de la cuenta de dominio mediante la eliminaci%n de la cuenta en el $rupo
<suarios del dominio y permitir ,ue la cuenta se utilice Hnicamente para iniciar la
sesi%n en e,uipos espec'ficos.
-utorizacin )asada en funciones
)a mayor'a de las aplicaciones .eb .9&- utili(an un enfo,ue de autori(aci%n basado
en funciones. Deber# considerar los distintos tipos de funciones y seleccionar los
m#s adecuados a su escenario de aplicaciones. Dispone de las si$uientes opciones0
1 Junciones de .9&-
1 Junciones de la aplicaci%n de Ser/icios &mpresariales 7COM:8
1 Junciones de base de datos definidas por el usuario de S4) Ser/er
1 Junciones de la aplicaci%n de S4) Ser/er

3unciones de %0(/
)as funciones de .9&- son muy flexibles y se basan en ob;etos I"rincipal ,ue
contienen la lista de funciones a las ,ue pertenece una identidad autenticada. )as
funciones de .9&- pueden utili(arse en aplicaciones .eb, ser/icios .eb o
componentes remotos alo;ados en AS".9&- 7y a los ,ue se obtiene acceso mediante
DttpChannel8.
)a autori(aci%n con funciones de .9&- puede reali(arse de forma declarati/a,
mediante llamadas a la clase "rincipal"ermission, o a tra/*s de un pro$rama,
mediante llamadas imperati/as a esta clase o utili(ando el m*todo
I"rincipal%IsInRole.
3unciones de %0(/ con autenticacin de Windows
Si la aplicaci%n utili(a la autenticaci%n de .indo6s, AS".9&- crea autom#ticamente
un ob;eto Windows"rincipal ,ue se ad;unta al contexto de la petici%n .eb actual
7mediante #ttpConte$t%&ser8. <na /e( ,ue finali(a el proceso de autenticaci%n y
AS".9&- ha ad;untado el ob;eto a la petici%n actual, se utili(a para todas las
autori(aciones basadas en funciones de .9&- posteriores.
)a pertenencia a $rupos de .indo6s del llamador autenticado sir/e para determinar
el con;unto de funciones. &n la autenticaci%n de .indo6s, las funciones de .9&-
e,ui/alen a los $rupos de .indo6s.
3unciones de %0(/ con autenticacin distinta de la de Windows
Si la aplicaci%n utili(a un mecanismo de autenticaci%n distinto del de .indo6s, como
Jormularios o "assport, deber# escribir c%di$o para crear un ob;eto
2eneric"rincipal 7o un ob;eto I"rincipal personali(ado8 y llenarlo con un con;unto
de funciones obtenido de un almac*n de datos de autenticaci%n personali(ado, como
por e;emplo, una base de datos de S4) Ser/er.
4)*etos I"rincipal personalizados
&l mecanismo de se$uridad basado en funciones de .9&- es extensible. "uede
desarrollar sus propias clases ,ue implementen I"rincipal e IIdentity y proporcionar
su propia funcionalidad ampliada de autori(aci%n basada en funciones.
)a funcionalidad de comprobaci%n de funciones b#sica est# ase$urada mientras el
ob;eto I"rincipal personali(ado 7,ue contiene funciones obtenidas de un almac*n de
datos personali(ado8 si$a estando ad;unto al contexto de la petici%n actual 7mediante
#ttpConte$t%&ser8.
Al implementar la interfa( I"rincipal, se $aranti(a el funcionamiento con la identidad
personali(ada tanto de la forma declarati/a como de la imperati/a de las peticiones
"rincipal"ermission. Adem#s, puede implementar una sem#ntica de funciones
ampliada, por e;emplo, con un m*todo adicional como IsInMultipleRoles5 string 67
roles 8 ,ue le permitir'a probar y afirmar la pertenencia de /arias funciones.
Ms informacin
1 "ara obtener m#s informaci%n acerca de c%mo utili(ar la autori(aci%n basada
en funciones de .9&-, consulte el cap'tulo Q, ESe$uridad de AS".9&-E.
1 "ara obtener m#s informaci%n acerca de la creaci%n de ob;etos
2eneric"rincipal, consulte EC%mo utili(ar la autenticaci%n mediante
Jormularios con ob;etos Neneric"rincipalE en la secci%n =eferencia de esta
$u'a.

3unciones de la aplicacin de Ser!icios (mpresariales
5C4M98
&l uso de funciones de la aplicaci%n de Ser/icios &mpresariales 7COM:8 mue/e los
controles de acceso al ni/el medio y le permite utili(ar la a$rupaci%n de conexiones
de bases de datos al establecer la conexi%n con bases de datos de ser/idor. 9o
obstante, para una autori(aci%n basada en funciones de la aplicaci%n de Ser/icios
&mpresariales 7COM:8 coherente, su aplicaci%n .eb cliente deber# suplantar y
transmitir la identidad del llamador ori$inal 7mediante un testi$o de acceso de
.indo6s8 a la aplicaci%n de Ser/icios &mpresariales. "ara ello, deber# incluir las
si$uientes entradas en el archi/o .eb.confi$ de la aplicaci%n .eb.
<authentication mode="Windows" />
<identity impersonate="true" />
Si el uso de controles declarati/os en los m*todos 7para determinar los usuarios ,ue
pueden llamar a cada m*todo8 resulta suficiente, podr# implementar la aplicaci%n y
actuali(ar la pertenencia a funciones mediante la herramienta de administraci%n
Ser/icios de componente.
Si re,uiere controles mediante pro$ramaci%n en el c%di$o de m*todos, perder#
al$unas de las /enta;as de administraci%n e implementaci%n de las funciones de la
aplicaci%n de Ser/icios &mpresariales 7COM:8, puesto ,ue la l%$ica de funciones no
se puede modificar.
3unciones de )ase de datos definidas por el usuario de
S: Ser!er
&n este enfo,ue, se crean funciones en la base de datos, se asi$nan permisos
basados en las funciones y se asi$nan cuentas de $rupo y de usuario de .indo6s a
las funciones. &ste enfo,ue re,uiere ,ue transmita la identidad del llamador al
ser/idor 7si utili(a la autenticaci%n de .indo6s recomendada para S4) Ser/er8.
3unciones de la aplicacin de S: Ser!er
&n este enfo,ue, los permisos se conceden a las funciones de la base de datos, pero
las funciones de la aplicaci%n de S4) Ser/er no contienen cuentas de usuario ni de
$rupo. "or lo tanto, perder# la $ranularidad del llamador ori$inal.
Con las funciones de aplicaci%n, se autori(a el acceso a una aplicaci%n espec'fica
7en lu$ar de a un con;unto de usuarios8. )a aplicaci%n acti/a la funci%n mediante un
procedimiento almacenado inte$rado ,ue acepta un nombre de funci%n y una
contrase+a. <na de las principales des/enta;as de este enfo,ue es ,ue re,uiere ,ue
la aplicaci%n administre las credenciales 7el nombre de funci%n y la contrase+a
correspondiente8 de forma se$ura.
Ms informacin
"ara obtener m#s informaci%n acerca de las funciones de base de datos definidas
por el usuario de S4) Ser/er y las funciones de la aplicaci%n de S4) Ser/er,
consulte el cap'tulo >, ESe$uridad del acceso a datosE.

Comparacin de las funciones de %0(/ y las funciones
de Ser!icios (mpresariales 5C4M98
)a tabla si$uiente contiene una comparaci%n de las caracter'sticas de las funciones
de .9&- y las funciones de la aplicaci%n de Ser/icios &mpresariales 7COM:8.
-abla @.0 Comparacin de las funciones de Servicios Empresariales con las
funciones de .NET

Caracter'stica Junciones de Ser/icios
&mpresariales
Junciones de .9&-
Administraci%n Derramienta de
administraci%n Ser/icios de
componente
"ersonali(ada
Almac*n de
datos
Cat#lo$o COM: Almac*n de datos personali(ado 7por
e;emplo, S4) Ser/er o Acti/e
Directory8
Declarati/as S'
RSecurity=ole7EMana$erE8S
S'
R"rincipal"ermission7
SecurityAction.Demand,
=oleTEMana$erE8S
?mperati/as S'
Context<til.?sCaller?n=ole78
S'
?"rincipal.?s?n=ole
Nranularidad
de clases,
interfaces y
m*todos
S' S'
&xtensibles 9o S'
7mediante una implementaci%n de
?"rincipal personali(ada8
Disponibles
para todos los
componentes
de .9&-
S%lo para componentes ,ue
se deri/an de la clase base
Ser/icedComponent.
S'
"ertenencia a
funciones
)as funciones contienen
cuentas de $rupo o de
usuario de .indo6s.
Al utili(ar ob;etos .indo6s"rincipal,
las funciones SO9 los $rupos de
.indo6s y no se re,uiere nin$Hn ni/el
de abstracci%n adicional.
=e,uieren
implementaci%
n de interfaces
expl'cita
S'
"ara obtener autori(aci%n
de m*todos, deber#
definirse e implementarse
expl'citamente una interfa(.
9o

&tilizar funciones de %0(/
)as funciones de .9&- le permiten prote$er los si$uientes elementos0
1 Archi/os
1 Carpetas
1 "#$inas .eb 7archi/os .aspx8
1 Ser/icios .eb 7archi/os .asmx8
1 Ob;etos
1 M*todos y propiedades
1 Plo,ues de c%di$o de m*todos

Al poder utili(ar funciones de .9&- para prote$er operaciones 7reali(adas por
m*todos y propiedades8 y blo,ues de c%di$o espec'ficos, podr# prote$er el acceso a
recursos locales y remotos a los ,ue tiene acceso la aplicaci%n.
0ota1 los cuatro primeros elementos de la lista anterior 7archi/os, carpetas,
p#$inas .eb y ser/icios .eb8 se prote$en mediante &rl-ut;orizationModule,
,ue puede utili(ar la pertenencia a funciones del llamador 7y la identidad de
llamador8 para tomar decisiones de autori(aci%n.
Si utili(a la autenticaci%n de .indo6s, la mayor'a de las tareas necesarias para
utili(ar funciones de .9&- se reali(an autom#ticamente. AS".9&- crea un ob;eto
Windows"rincipal y la pertenencia a $rupos de .indo6s del usuario determina el
con;unto de funciones asociado.
"ara utili(ar funciones de .9&- con un mecanismo de autenticaci%n distinto del de
.indo6s, deber# escribir c%di$o para0
1 Capturar las credenciales del usuario
1 Validar las credenciales del usuario en un almac*n de datos personali(ado,
como por e;emplo, una base de datos de S4) Ser/er
1 =ecuperar una lista de funciones, crear un ob;eto 2eneric"rincipal y asociarlo
a la petici%n .eb actual
&l ob;eto 2eneric"rincipal representa al usuario autenticado y se utili(a en
comprobaciones de funciones de .9&- posteriores, como las peticiones
"rincipal"ermission declarati/as y las comprobaciones de
I"rincipal%IsInRole mediante pro$ramaci%n.

Ms informacin
"ara obtener m#s informaci%n acerca del proceso de creaci%n de un ob;eto
2eneric"rincipal para la autenticaci%n mediante Jormularios, consulte el cap'tulo Q,
ESe$uridad de AS".9&-E.
Compro)ar la pertenencia a funciones
Se encuentran disponibles los si$uientes tipos de comprobaciones de funciones
de .9&-0
Importante1 la comprobaci%n de funciones de .9&- se basa en la asociaci%n de
un ob;eto I"rincipal 7,ue representa al usuario autenticado8 a la petici%n actual.
&n las aplicaciones .eb AS".9&-, el ob;eto I"rincipal debe estar /inculado a
#ttpConte$t%&ser. &n las aplicaciones de Jormularios de .indo6s, el ob;eto
I"rincipal debe estar /inculado a /;read%Current"rincipal.
1 Compro)aciones de funciones manuales. "ara la autori(aci%n espec'fica,
puede llamar al m*todo I"rincipal%IsInRole para ,ue autorice el acceso a
blo,ues de c%di$o determinados en funci%n de la pertenencia a funciones del
llamador. "uede utili(arse tanto l%$ica A9D como O= para comprobar la
pertenencia a funciones.
1 Compro)aciones de funciones declarati!as 5puertas a los m<todos8.
"uede anotar m*todos con la clase "rincipal"ermission-ttri)ute 7,ue se
puede abre/iar como "rincipal"ermission8 para exi$ir la pertenencia a
funciones mediante declaraciones. Se admite solamente la l%$ica O=. "or
e;emplo, puede exi$ir ,ue un llamador pertene(ca al menos a una funci%n
espec'fica 7por e;emplo, el llamador debe ser un ca;ero o un director8. 9o se
puede especificar ,ue el llamador sea director y ca;ero mediante las
comprobaciones declarati/as.
1 Compro)aciones de funciones imperati!as 5compro)aciones en los
m<todos8. "uede llamar a "rincipal"ermission%Demand en el c%di$o para
e;ecutar l%$ica de autori(aci%n espec'fica. Se admiten las operaciones l%$icas
A9D y O=.

(*emplos de compro)acin de funciones
)os si$uientes fra$mentos de c%di$o muestran /arias comprobaciones de funciones
de e;emplo mediante pro$ramaci%n y t*cnicas declarati/as e imperati/as.
Autori(ar a Pob a reali(ar una operaci%n0
0ota1 aun,ue puede autori(ar a usuarios indi/iduales, en $eneral deber#
reali(ar la autori(aci%n en funci%n de la pertenencia a funciones, lo ,ue le
permite autori(ar a con;untos de usuarios ,ue comparten los mismos
pri/ile$ios en la aplicaci%n.
1 Comprobaci%n directa de nombre de usuario
GenericIdentity userIdentity = new GenericIdentity("Bob");
if (userIdentity.Name=="Bob")
{
}
1 Comprobaci%n declarati/a
[PrincipalPermissionAttribute(SecurityAction.Demand, User="Bob")]
public void DoPrivilegedMethod()
{
}
1 Comprobaci%n imperati/a
PrincipalPermission permCheckUser = new PrincipalPermission(
"Bob", null);
permCheckUser.Demand();
Autori(ar a ca;eros 7tellers8 a reali(ar una operaci%n0
1 Comprobaci%n directa de nombre de funci%n
GenericIdentity userIdentity = new GenericIdentity("Bob");
// Role names would be retrieved from a custom data store
string[] roles = new String[]{"Manager", "Teller"};
GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity,
roles);
if (userPrincipal.IsInRole("Teller"))
{
}
1 Comprobaci%n declarati/a
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller")]
void SomeTellerOnlyMethod()
{
}
1 Comprobaci%n imperati/a
public SomeMethod()
{
PrincipalPermission permCheck = new PrincipalPermission(
null,"Teller");
permCheck.Demand();
// Only Tellers can execute the following code
// Non members of the Teller role result in a security exception
. . .
}
Autori(ar a los directores 7managers o 7O=8 ca;eros a reali(ar una operaci%n0
1 Comprobaci%n directa de nombre de funci%n
if (Thread.CurrentPrincipal.IsInRole("Teller") ||
Thread.CurrentPrincipal.IsInRole("Manager"))
{
// Perform privileged operations
}
1 Comprobaci%n declarati/a
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller"),
PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
public void DoPrivilegedMethod()
{

}
1 Comprobaci%n imperati/a
PrincipalPermission permCheckTellers = new PrincipalPermission(
null,"Teller");
PrincipalPermission permCheckManagers = new PrincipalPermission(
null,"Manager");
(permCheckTellers.Union(permCheckManagers)).Demand();
Autori(ar solamente a las personas ,ue son directores y 7A9D8 ca;eros a reali(ar
la operaci%n0
1 Comprobaci%n directa de nombre de funci%n
if (Thread.CurrentPrincipal.IsInRole("Teller") &&
Thread.CurrentPrincipal.IsInRole("Manager"))
{
// Perform privileged operation
}
1 Comprobaci%n declarati/a
9o se pueden reali(ar comprobaciones A9D con las funciones de .9&- de
forma declarati/a. )a a$rupaci%n de peticiones "rincipal"ermission crea
una operaci%n O= l%$ica.
1 Comprobaci%n imperati/a
PrincipalPermission permCheckTellers = new PrincipalPermission(
null,"Teller");
permCheckTellers.Demand();
PrincipalPermission permCheckManagers = new PrincipalPermission(
null, "Manager");
permCheckManagers.Demand();
Seleccionar un mecanismo de autenticacin
&sta secci%n contiene instrucciones dise+adas para ayudarle a seleccionar un
mecanismo de autenticaci%n adecuado a escenarios de aplicaciones habituales. &n
primer lu$ar, deber# considerar los si$uientes aspectos0
1 Identidades. &l mecanismo de autenticaci%n de .indo6s s%lo es adecuado si
los usuarios de la aplicaci%n tienen cuentas de .indo6s ,ue pueda autenticar
una autoridad de confian(a a la ,ue ten$a acceso el ser/idor .eb de la
aplicaci%n.
1 -dministracin de credenciales. <na de las /enta;as cla/e de la
autenticaci%n de .indo6s reside en ,ue le permite de;ar ,ue el sistema
operati/o se encar$ue de la administraci%n de credenciales. &n otros enfo,ues
distintos de .indo6s, como la autenticaci%n mediante Jormularios, deber#
considerar detenidamente la ubicaci%n y el modo de almacenamiento de las
credenciales de usuario. )os dos enfo,ues m#s habituales consisten en
utili(ar0
1 Pases de datos de S4) Ser/er
1 Ob;etos de usuario en Acti/e Directory

"ara obtener m#s informaci%n acerca de las consideraciones de se$uridad del
uso de S4) Ser/er como almac*n de credenciales, consulte el cap'tulo >,
ESe$uridad del acceso a datosE.
"ara obtener m#s informaci%n acerca del uso de la autenticaci%n mediante
Jormularios en almacenes de datos personali(ados, consulte el cap'tulo Q,
ESe$uridad de AS".9&-E.
1 /ransmisin de la identidad. 29ecesita implementar un modelo de
suplantaci%nFdele$aci%n y transmitir el contexto de se$uridad del llamador
ori$inal por los ni/eles en el sistema operati/o3 "or e;emplo, para admitir la
auditor'a o la autori(aci%n por usuario 7$ranular8. &n caso afirmati/o, deber#
poder suplantar al llamador y dele$ar su contexto de se$uridad al subsistema
si$uiente de ni/el inferior, tal y como se describe en la secci%n EDele$aci%nE
anterior de este cap'tulo.
1 /ipo de e$plorador. 2<tili(an ?nternet &xplorer todos sus usuarios o necesita
poder admitir una base de usuarios con distintos tipos de explorador3 )a tabla
@.@ muestra los mecanismos de autenticaci%n ,ue re,uieren exploradores
?nternet &xplorer y los ,ue admiten /arios tipos de exploradores.
-abla @.@0 !e"uisitos de e#plorador para la autenticacin
-ipo de autenticaci%n =e,uiere
?nternet
&xplorer
9otas
Jormularios 9o
"assport 9o
?nte$rada en .indo6s
7Ierberos o 9-)M8
S' Ierberos re,uiere tambi*n el sistema
operati/o .indo6s !!! o posterior en los
e,uipos cliente y ser/idor, y cuentas
confi$uradas para la dele$aci%n. "ara
obtener m#s informaci%n, consulte EC%mo0
?mplementar la dele$aci%n Ierberos en
.indo6s !!!E en la secci%n =eferencia de
esta $u'a.
P#sica 9o )a autenticaci%n b#sica forma parte del
protocolo D--" >.> ,ue admiten casi todos
los exploradores.
?mpl'cita S'
Certificados 9o )os clientes re,uieren certificados U.B!V.

(scenarios de Internet
&n los escenarios de ?nternet, se presupone ,ue0
1 )os usuarios no tienen cuentas de .indo6s en el dominio del ser/idor ni en un
dominio de confian(a al ,ue tiene acceso el ser/idor.
1 )os usuarios no tienen certificados de cliente.

)a ilustraci%n @.A muestra un #rbol de decisi%n para la elecci%n de un mecanismo de
autenticaci%n para escenarios de ?nternet.
{nsert !gure" C#$3 - C,oosing an nternet Aut,entication *ec,anism.gi' (
?lustraci%n @.A
Seleccionar un mecanismo de autenticacin para aplicaciones de Internet
"ara obtener m#s informaci%n acerca de la se$uridad de los ser/icios .eb y la
especificaci%n .SWSecurity, ,ue forma parte de la iniciati/a Ar,uitectura $lobal de
UM) 7NUA8, consulte el cap'tulo >!, ESe$uridad de ser/icios .ebE.
Comparacin de 3ormularios y "assport
&sta secci%n resume las /enta;as de la autenticaci%n mediante Jormularios y de
"assport.
,enta*as de la autenticacin mediante 3ormularios
1 Admite la autenticaci%n en un almac*n de datos personali(ado, ,ue suele ser
una base de datos de S4) Ser/er o Acti/e Directory.
1 Admite la autori(aci%n basada en funciones con consultas de funciones desde
un almac*n de datos.
1 Se inte$ra a la perfecci%n con la interfa( de usuario .eb.
1 AS".9&- proporciona la mayor parte de la infraestructura. Se re,uiere poco
c%di$o personali(ado en comparaci%n con AS" cl#sico.

,enta*as de la autenticacin de "assport
1 "assport es una soluci%n centrali(ada.
1 &limina los problemas de administraci%n de credenciales de la aplicaci%n.
1 "uede utili(arse con es,uemas de autori(aci%n basada en funciones.
1 &s muy se$ura, puesto ,ue se basa en tecnolo$'as cripto$r#ficas.

Ms informacin
1 "ara obtener m#s informaci%n acerca de los enfo,ues de autenticaci%n de los
ser/icios .eb, consulte el cap'tulo >!, ESe$uridad de ser/icios .ebE.
1 "ara obtener m#s informaci%n acerca del uso de la autenticaci%n mediante
Jormularios con S4) Ser/er, consulte EC%mo0 <tili(ar la autenticaci%n
mediante Jormularios con S4) Ser/er !!!E en la secci%n =eferencia de esta
$u'a.

(scenarios de intranet y e$tranet
)a ilustraci%n @.B muestra un #rbol de decisi%n ,ue puede utili(arse para seleccionar
un mecanismo de autenticaci%n para los escenarios de aplicaciones de intranet y
extranet.
{nsert !gure" C#$3 ) C,oosing an E-tranet . nternet Aut,entication.gi'(
?lustraci%n @.B
Seleccionar un mecanismo de autenticacin para aplicaciones de intranet y
extranet
Comparacin de mecanismos de autenticacin
)a si$uiente tabla contiene una comparaci%n de los mecanismos de autenticaci%n
disponibles.
-abla @.A0 $%todos de autenticacin disponi&les
P#sic
a
?mpl'cit
a
9-)M Ierberos Certifi
cados
Jormu
larios
"assport
)os usuarios
necesitan
cuentas de
.indo6s en
el dominio
S' S' S' S' 9o 9o 9o
del ser/idor.
Admite la
dele$aci%nX.
S' 9o 9o S' "osibl
e
S' S'
=e,uiere
clientes y
ser/idores
de .indo6s
!!!.
9o S' 9o S' 9o 9o 9o
)as
credenciales
se
transmiten
como texto
no cifrado
7re,uiere
SS)8.
S' 9o 9o 9o 9o S' 9o
Admite otros
exploradores
aparte de ?&.
S' 9o 9o 9o S' S' S'

X "ara obtener m#s informaci%n, consulte el tema EDele$aci%nE en la secci%n
E-ransmitir la identidadE anterior de este cap'tulo.
Conclusin
&l dise+o de enfo,ues de autenticaci%n y autori(aci%n de aplicaciones distribuidas
constituye un /erdadero reto. &l disponer de un dise+o adecuado de la
autenticaci%n y la autori(aci%n durante las primeras fases del desarrollo de la
aplicaci%n ayuda a miti$ar muchos de los peores ries$os de se$uridad. A
continuaci%n, fi$ura un resumen de la informaci%n de este cap'tulo0
1 <tilice el modelo de acceso a recursos de subsistemas de confian(a para
poder beneficiarse de la a$rupaci%n de conexiones de bases de datos.
1 Si su aplicaci%n no utili(a la autenticaci%n de .indo6s, utilice la comprobaci%n
de funciones de .9&- para la autori(aci%n. Valide las credenciales en un
almac*n de datos personali(ado, recupere una lista de funciones y cree un
ob;eto 2eneric"rincipal. As%cielo a la petici%n .eb actual
7#ttpConte$t%&ser8.
1 Si su aplicaci%n utili(a la autenticaci%n de .indo6s pero no la aplicaci%n de
Ser/icios &mpresariales, utilice funciones de .9&-. 9o ol/ide ,ue en la
autenticaci%n de .indo6s, las funciones de .9&- son $rupos de .indo6s.
1 Si su aplicaci%n utili(a la autenticaci%n de .indo6s y la aplicaci%n de Ser/icios
&mpresariales, considere la posibilidad de utili(ar funciones de Ser/icios
&mpresariales 7COM:8.
1 "ara una autori(aci%n coherente basada en funciones con funciones de la
aplicaci%n de Ser/icios &mpresariales 7COM:8, la identidad del llamador
ori$inal deber# transmitirse a la aplicaci%n de Ser/icios &mpresariales. Si se
llama a la aplicaci%n de Ser/icios &mpresariales desde una aplicaci%n .eb
AS".9&-, la aplicaci%n .eb deber# utili(ar la autenticaci%n de .indo6s y
estar confi$urada para la suplantaci%n.
1 Anote m*todos con el atributo "rincipal"ermission para exi$ir la pertenencia
a funciones de forma declarati/a. 9o se llama a este m*todo si el llamador no
fi$ura en la funci%n especificada y se $enera una excepci%n de se$uridad.
1 )lame a "rincipal"ermission%Demand en c%di$o de m*todos 7o utilice
I"rincipal%IsInRole8 para tomar decisiones de autori(aci%n espec'fica.
1 Considere la posibilidad de implementar un ob;eto I"rincipal personali(ado
para aumentar la sem#ntica de comprobaci%n de funciones.