Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:services:it_security:aai:serviceowner [2024/01/31 17:24] – [Setting up your Service Provider (SP)] | en:services:it_security:aai:serviceowner [2024/01/31 17:28] (current) – [Setting up your Service Provider (SP)] | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ======Guideline for Service Owners ====== | ||
| + | ===== Connecting to our Identity Providers (IdPs) ===== | ||
| + | We provide you with the flexibility to connect your services to our IdP solutions through two protocols: SAML and OIDC. These protocols ensure a secure and smooth integration, | ||
| + | ==== 1: Security Assertion Markup Language (SAML):==== | ||
| + | SAML allows for secure single sign-on (SSO) and federation across different applications and platforms. It enables the exchange of user authentication and authorization information in a standardized way, ensuring smooth communication between your services and our IdPs. | ||
| + | === GWDG Academic ID SAML Solutions: === | ||
| + | |||
| + | == SimpleSAMLphp: | ||
| + | SimpleSAMLphp (https:// | ||
| + | |||
| + | == Shibboleth: | ||
| + | Shibboleth (https:// | ||
| + | |||
| + | === Information We Need from You:=== | ||
| + | To connect your services to our SAML SSO solution, we request the following information from you: | ||
| + | * SP Metadata (Mandatory): | ||
| + | * Authorization Policies (Optional): Provide us with the information and conditions on whom and how they can access your services. Example: Only students from the University " | ||
| + | | ||
| + | Once you have collected this information, | ||
| + | |||
| + | === Information You Need from Us: === | ||
| + | We will provide you with the necessary SAML metadata, which is an XML document containing important configuration details about the IdP you requested to connect. The metadata includes information such as URLs of endpoints, supported bindings, identifiers, | ||
| + | Depending on your application framework or platform, you will need to locate the appropriate configuration file or settings where you can specify the IdP's metadata. This step ensures that your application recognizes and trusts our IdP. If your application doesn' | ||
| + | After completing the configuration, | ||
| + | |||
| + | |||
| + | ==== 2: OpenID Connect (OIDC):==== | ||
| + | In addition to SAML, we support OIDC as an alternative protocol for integrating your services with our IdPs. OIDC is an identity layer built on top of the OAuth 2.0 framework. It extends the OAuth 2.0 authorization protocol to provide an additional authentication protocol. OIDC allows third-party applications to verify the identity of end-users and obtain basic user profile information. It uses JSON web tokens (JWTs) to exchange information between the client application and the OpenID Provider (OP). | ||
| + | |||
| + | |||
| + | === GWDG Academic ID OIDC Solution: === | ||
| + | |||
| + | == Keycloak:== | ||
| + | | ||
| + | |||
| + | * Extensible Customization: | ||
| + | * Delegated Authentication: | ||
| + | * Delegated IdM: Keycloak supports the management of user identities and admin access centrally. However, it also offers an easy solution for connecting to user directories such as Active Directory and LDAP that currently exist in a domain. | ||
| + | * Customized AM Mechanisms: Keycloak supports various AM mechanisms, including MFA, one-time password (OTP), and customized policies. Service owners can also request a combination of these mechanisms to authenticate and authorize users. | ||
| + | |||
| + | === Information We Need from You:=== | ||
| + | To connect your services to our OIDC solution, we require the following information from you: | ||
| + | * Base URIs (Mandatory): | ||
| + | * Redirect URIs (Mandatory): | ||
| + | * Scopes (Optional): | ||
| + | * Authorization Flow (Optional): You have the flexibility to choose the desired authorization flow for your application. OIDC supports various flows, such as the Authorization Code Flow, Implicit Flow, and Hybrid Flow. Each flow has its own characteristics and security considerations. Select the appropriate flow based on your application' | ||
| + | * Authorization Policies (Optional): Refer to SAML. | ||
| + | === Information You Need from Us: === | ||
| + | Once you submit the required information, | ||
| + | Similar to the SAML connection, if your application doesn' | ||
| + | Please ensure that you follow the configuration steps carefully, handle received tokens securely within your application, | ||
| + | |||
| + | |||
| + | ==== Which Protocol Is the Best Choice for You? SAML or OIDC:==== | ||
| + | When considering whether to choose SAML or OIDC for integrating your services with our IdM or IdP solutions, it's essential to evaluate the specific benefits each protocol offers. Here are some key arguments to help you make an informed decision: | ||
| + | |||
| + | * You need modern authentication and authorization features: OIDC builds upon OAuth 2.0 and offers additional features for modern identity management, including support for mobile and web applications, | ||
| + | * Simplicity and ease of implementation: | ||
| + | * Industry adoption and compatibility: | ||
| + | * Compliance and regulatory considerations: | ||
| + | |||
| + | Ultimately, the best choice depends on factors such as your existing infrastructure, | ||
| + | ===== 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) ===== | ||
| + | |||
| + | | ||
| + | |||
| + | 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 / | ||
| + | </ | ||
| + | </ | ||