Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:services:it_security:aai:serviceowner [2024/01/31 15:01] – sdabbag | en:services:it_security:aai:serviceowner [2024/01/31 17:28] (current) – [Setting up your Service Provider (SP)] sdabbag | ||
---|---|---|---|
Line 63: | Line 63: | ||
Ultimately, the best choice depends on factors such as your existing infrastructure, | Ultimately, the best choice depends on factors such as your existing infrastructure, | ||
===== Hosting IdPs ===== | ===== Hosting IdPs ===== | ||
+ | At GWDG, we offer comprehensive solutions for hosting IdPs, ensuring the secure storage and management of user identities. Our services include establishing and configuring IdPs tailored to your specific requirements. Whether you prefer cloud-hosted solutions or on-premises installations, | ||
+ | Our process for setting up IdPs and integrating them into your domains is straightforward. Here's an overview of how we can assist you: | ||
+ | |||
+ | |||
+ | |||
+ | * Evaluation: Our team will work closely with you to understand your requirements and recommend the most suitable IdP solution for your organization. | ||
+ | * Configuration: | ||
+ | * Integration: | ||
+ | * Testing and Deployment: We will conduct thorough testing to ensure everything functions smoothly. Once validated, we will assist you in deploying the IdP into your production environment. | ||
+ | * Registration in DFN and Other Federations: | ||
+ | * Ongoing Support and Maintenance: | ||
+ | |||
+ | |||
+ | Our goal is to make the IdP setup and integration process as smooth as possible, empowering you to provide a secure and streamlined user experience. With our assistance, you can focus on delivering your core services while leaving the technical complexities to us. | ||
+ | |||
+ | If you have any questions or require further information, | ||
===== Setting up your Service Provider (SP) ===== | ===== Setting up your Service Provider (SP) ===== | ||
+ | | ||
+ | |||
+ | Two widely recognized options for SAML2 SSO integration into your application are the Apache module mod_shib paired with shibboleth SP and SimpleSamlPHP. The former follows a generic approach as it relies on the Apache webserver for authentication, | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | ** Example: Installation Guideline** | ||
+ | |||
+ | |||
+ | This guide has been tested on Debian 8 and 9 but should work similar on ubuntu installations. For other distributions consult the official Shibboleth documentation. | ||
+ | |||
+ | 1. Install packges: '' | ||
+ | |||
+ | 2. Configure ''/ | ||
+ | * entityID: Use your identifier for this SP e.g. '' | ||
+ | * SSO: The url of the metadata for the GWDG SSO instance which will be used to start an authentication workflow: | ||
+ | * MetadataProvider: | ||
+ | type=" | ||
+ | uri=" | ||
+ | backingFilePath="/ | ||
+ | reloadInterval=" | ||
+ | </ | ||
+ | 3. Configure ''/ | ||
+ | 4. Configure apache to protect routes with shibboleth authentication. A protected location could look like this: | ||
+ | ''< | ||
+ | AuthType shibboleth | ||
+ | require valid-user | ||
+ | </ | ||
+ | | ||
+ | 5. Restart apache and shibd: '' | ||
+ | |||
+ | 6. Check if your metadata is available. It should be found at '' | ||
+ | |||
+ | 7. Open an issue in this github project to have your metadata configured in the sso. Provide either the autoconfigured or hosted metadata link in there. | ||
+ | |||
+ | ---- | ||
+ | ** Example: Configuration** | ||
+ | |||
+ | |||
+ | ''/ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | xmlns: | ||
+ | xmlns: | ||
+ | xmlns: | ||
+ | xmlns: | ||
+ | clockSkew=" | ||
+ | |||
+ | <!-- | ||
+ | By default, in-memory StorageService, | ||
+ | are used. See example-shibboleth2.xml for samples of explicitly configuring them. | ||
+ | --> | ||
+ | |||
+ | <!-- | ||
+ | To customize behavior for specific resources on Apache, and to link vhosts or | ||
+ | resources to ApplicationOverride settings below, use web server options/ | ||
+ | See https:// | ||
+ | | ||
+ | For examples with the RequestMap XML syntax instead, see the example-shibboleth2.xml | ||
+ | file, and the https:// | ||
+ | --> | ||
+ | |||
+ | <!-- The ApplicationDefaults element is where most of Shibboleth' | ||
+ | < | ||
+ | | ||
+ | |||
+ | <!-- | ||
+ | Controls session lifetimes, address checks, cookie handling, and the protocol handlers. | ||
+ | You MUST supply an effectively unique handlerURL value for each of your applications. | ||
+ | The value defaults to / | ||
+ | a relative value based on the virtual host. Using handlerSSL=" | ||
+ | the protocol to be https. You should also set cookieProps to " | ||
+ | Note that while we default checkAddress to " | ||
+ | security of your site. Stealing sessions via cookie theft is much easier with this disabled. | ||
+ | --> | ||
+ | < | ||
+ | checkAddress=" | ||
+ | |||
+ | <!-- | ||
+ | Configures SSO for a default IdP. To allow for >1 IdP, remove | ||
+ | entityID property and adjust discoveryURL to point to discovery service. | ||
+ | (Set discoveryProtocol to " | ||
+ | You can also override entityID on /Login query string, or in RequestMap/ | ||
+ | --> | ||
+ | <SSO entityID=" | ||
+ | SAML2 SAML1 | ||
+ | </ | ||
+ | |||
+ | <!-- SAML and local-only logout. --> | ||
+ | < | ||
+ | | ||
+ | <!-- Extension service that generates " | ||
+ | <Handler type=" | ||
+ | |||
+ | <!-- Status reporting service. --> | ||
+ | <Handler type=" | ||
+ | |||
+ | <!-- Session diagnostic service. --> | ||
+ | <Handler type=" | ||
+ | |||
+ | <!-- JSON feed of discovery information. --> | ||
+ | <Handler type=" | ||
+ | </ | ||
+ | |||
+ | <!-- | ||
+ | Allows overriding of error template information/ | ||
+ | also add attributes with values that can be plugged into the templates. | ||
+ | --> | ||
+ | <Errors supportContact=" | ||
+ | helpLocation="/ | ||
+ | styleSheet="/ | ||
+ | | ||
+ | < | ||
+ | type=" | ||
+ | uri=" | ||
+ | backingFilePath="/ | ||
+ | reloadInterval=" | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | <!-- Example of remotely supplied batch of signed metadata. --> | ||
+ | <!-- | ||
+ | < | ||
+ | backingFilePath=" | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | --> | ||
+ | |||
+ | <!-- Example of locally maintained metadata. --> | ||
+ | <!-- | ||
+ | < | ||
+ | --> | ||
+ | |||
+ | <!-- Map to extract attributes from SAML assertions. --> | ||
+ | < | ||
+ | | ||
+ | <!-- Use a SAML query if no attributes are supplied during SSO. --> | ||
+ | < | ||
+ | |||
+ | <!-- Default filtering policy for recognized attributes, lets other data pass. --> | ||
+ | < | ||
+ | |||
+ | <!-- Simple file-based resolver for using a single keypair. --> | ||
+ | < | ||
+ | |||
+ | <!-- | ||
+ | The default settings can be overridden by creating ApplicationOverride elements (see | ||
+ | the https:// | ||
+ | Resource requests are mapped by web server commands, or the RequestMapper, | ||
+ | applicationId setting. | ||
+ | | ||
+ | Example of a second application (for a second vhost) that has a different entityID. | ||
+ | Resources on the vhost would map to an applicationId of " | ||
+ | --> | ||
+ | <!-- | ||
+ | < | ||
+ | --> | ||
+ | </ | ||
+ | | ||
+ | <!-- Policies that determine how to process and authenticate runtime messages. --> | ||
+ | < | ||
+ | |||
+ | <!-- Low-level configuration about protocols and bindings available for use. --> | ||
+ | < | ||
+ | |||
+ | </ | ||
+ | </ | ||
+ | |||
+ | |||
+ | ''/ | ||
+ | < | ||
+ | |||
+ | <!-- | ||
+ | The mappings are a mix of SAML 1.1 and SAML 2.0 attribute names agreed to within the Shibboleth | ||
+ | community. The non-OID URNs are SAML 1.1 names and most of the OIDs are SAML 2.0 names, with a | ||
+ | few exceptions for newer attributes where the name is the same for both versions. You will | ||
+ | usually want to uncomment or map the names for both SAML versions as a unit. | ||
+ | --> | ||
+ | | ||
+ | <!-- First some useful eduPerson attributes that many sites might use. --> | ||
+ | | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | | ||
+ | < | ||
+ | |||
+ | < | ||
+ | | ||
+ | < | ||
+ | |||
+ | |||
+ | <!-- A persistent id attribute that supports personalized anonymous access. --> | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- Second, an alternate decoder that will decode the incorrect form into the newer form. --> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | --> | ||
+ | | ||
+ | <!-- Third, the new version (note the OID-style name): --> | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | <!-- Fourth, the SAML 2.0 NameID Format: --> | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | | ||
+ | <!-- Some more eduPerson attributes, uncomment these to use them... --> | ||
+ | <!-- | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | |||
+ | --> | ||
+ | |||
+ | <!-- Examples of LDAP-based attributes, uncomment to use these... --> | ||
+ | <!-- | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | --> | ||
+ | |||
+ | </ | ||
+ | </ | ||
+ | |||
+ | **/ | ||
+ | < | ||
+ | < | ||
+ | DocumentRoot / | ||
+ | < | ||
+ | Options FollowSymLinks | ||
+ | AllowOverride None | ||
+ | </ | ||
+ | < | ||
+ | Options Indexes FollowSymLinks | ||
+ | AllowOverride All | ||
+ | Order allow,deny | ||
+ | allow from all | ||
+ | </ | ||
+ | # always fill env with shib variable | ||
+ | < | ||
+ | AuthType shibboleth | ||
+ | ShibRequestSetting requireSession false | ||
+ | Require shibboleth | ||
+ | </ | ||
+ | < | ||
+ | AuthType shibboleth | ||
+ | ShibRequireSession On | ||
+ | ShibUseHeaders Off | ||
+ | ShibExportAssertion On | ||
+ | require valid-user | ||
+ | </ | ||
+ | ServerName sp.example.org | ||
+ | UseCanonicalName On | ||
+ | SSLCertificateFile / | ||
+ | SSLCertificateKeyFile / | ||
+ | Include / | ||
+ | </ | ||
+ | </ |