ShibbolethSPApplicationModel¶
Introduccion:¶
Referencia principal:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationModel
The most confusing aspect of the SP software for beginners, aside from all the SAML and federation concepts, is how the software relates to the applications and resources it's being used to protect. Early use tends to lead to a lot of common questions:
- Why do I need to install the software on every web server? (Answer here)
- Can I protect multiple "applications" at the same time?
- What if I'm just hosting a few static web pages?
- Can I use multiple virtual hosts? Do I have to use separate virtual hosts?
- What if my application is running across multiple physical servers?
Application model at a logical level:¶
An "application" is a collection of resources that are grouped together in the SP configuration and behave as a unit with respect to the functions the SP performs, including session management.
Illustrating concepts:
¿Porqué una nueva aplicación?¶
So to put this concretely, if you have a server hosting two directories called "foo" and "bar", then the only way you can get an IdP to treat a request for authentication to "foo" and "bar" differently is to make the two directories logically distinct SPs, each with its own unique entityID. By "differently", we might mean releasing different SAML attributes to each one, or presenting a distinct login page in each case, or even refusing to respond at all.
Do you really need to create a new application?
Ver "Valid and Invalid Reasons for Additional Applications" en https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride
Definiendo una nueva aplicacion¶
En una instalación por defecto, tenemos un SP fisico, un SP logico, y una aplicacion (default Application).
Si se quiere definir una nueva aplicación en el SP, o un nuevo SP logico:
- Definir un nuevo applicationId
- Configurar recursos web asociados (tipicamente apache config, usando directiva Location)
- Definir <ApplicationOverride> en shibboleth2.xml e indicar dentro de ese elemento la configuración para esa nueva aplicacion.
Aplican reglas de herencia de configuración, ver referencia.
Si un SP fisico se quiere dividir en dos aplicaciones:
The application is intended to take up the whole of a different virtual host, or is part of a web tree on a virtual host that includes multiple applications?
- Opcion 1: separacion por virtual host. Separation by virtual host is the recommended approach because it allows the new application to inherit the default application handlerURL of "/Shibboleth.sso" and greatly limits the amount of additional configuration work. It's also more secure. Ejemplo:
- vhost1 - (logical)SP 1 with entityId1 - application 1 (default)
- vhost2 - (logical)SP 2 with entityId2 - application 2 (applicationId=2)
- Opcion 2: Dividing up a virtual host, on the other hand, requires that you supply at minimum a new <Sessions> element with all of the necessary settings inside, particularly a distinct handlerURL that will be unique to, and be part of, the new application.
Configuración: Application Override¶
Ref: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride
One of the most common things you'll do when creating an override is to assign it a special entityID, making it a distinct logical SP living inside the same physical installation (sometimes called "virtualize the SP"). This is done by adding an entityID property to the <ApplicationOverride> element:
<ApplicationOverride id="myappname" entityID="https://myapp.example.org/shibboleth"/>
SP config <<<<<<<<<<<<< MOVER A SHIB SP CONFIG¶
shibboleth2.xml main sections:
- <RequestMapper> habitualmente omitido, se usan comandos apache
- <ApplicationDefaults>
WebSSO, tiene dos partes principales:
1. Inicio de la interacción SessionInitiator genera AuthnRequest o envia a DiscoveryService (DS)
2. Receive Response from IdP - Assertion Consumer Service (ACS): https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAssertionConsumerService
Elemento <SSO> en shibboleth2.xml representa servicio que agrupa funciones de los dos anteriores.
Otras referencias: SWITCH¶
- Ejemplo con 1 host, 2 vhost.
- Separate entityID for each resource, (create keypairs for each)
- Each resource-logicalSP as separate entities with its respective att reqs.
- => 1 Phis. SP --> 2 Log. SP
Otras referencias: UMBC¶
https://wiki.umbc.edu/display/MW/Configuring+and+Testing+a+New+Shibboleth+SP
Menciona escenario con una aplicacion con dos vhost, con un ACS para cada vhost.
Fragmento: Note about virtual hosts
If your web server includes one or more virtual hosts, and you want the SP to handle requests for these hosts, you need to add an extra set of Assertion Consumer Service (ACS) URLs for each virtual host to the SP's metadata. Just copy the default set of URLs and replace the domain names with the domain name of the virtual host. For example, if one of the ACS URLs is https://www.umbc.edu/Shibboleth.sso/SAML2/POST, and you want the SP to handle the virtual host aok.lib.umbc.edu, you need to add an ACS URL https://aok.lib.umbc.edu/Shibboleth.sso/SAML2/POST
Comentarios relacionados con esta opcion (NativeSPApplicationModel):
[An SP-application] includes one or more unique handlerURL locations that are specific to the application and are associated only with it. Requests to SP handlers, such as Assertion Consumer Services and Session Initiators, are always prefixed with this URL and are grouped together into the set of resources that make up the application. Usually this URL will contain the path /Shibboleth.sso. There is usually only a single such URL, but if an application spans multiple virtual hosts, then each of those virtual hosts will have its own (usually automatically generated) handlerURL.
Ejemplo configuración (ambiente sp-test).¶
Escenario: se parte de la configuración por defecto del SP (1 SP fisico, 1 SP logico, 1 aplicacion (default)) y se agrega un segundo virtual host. En este caso no se consideró necesario agregar un nuevo SP logico o aplicación, por lo tanto solamente se agregó un ACS (AssertionConsumerService) para el segundo virtual host.
Detalles de la configuración:
- El SP inicialmente está en el host sp-test.seciu.edu.uy, con entityID=https://sp-test.seciu.edu.uy/idp/shibboleth
- Se agrega el virtual host con ServerName forma-desa.seciu.edu.uy.
- En la metadata del SP, se agrega el ACS para el nuevo virtual host, para esto se copia el ACS original, correspondiente al binding que se utiliza (HTTP-POST), y se modifica indicando el nombre de host nuevo y se ajusta el index para que no quede duplicado. Ejemplo de ACS agregado:
1 <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 2 Location="https://forma-desa.seciu.edu.uy/Shibboleth.sso/SAML2/POST" index="7"/>
