This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

In a single sign on system there are two roles; Service Providers and Identity Providers. The important characteristic of a single sign on system is the pre-defined trust relationship between the service providers and the identity providers. Service providers trust the assertions issued by the identity providers and the identity providers issue assertions based on the results of authentication and authorization of principles which access services on the service provider's side.

SAML 2.0 web browser-based single-sign-on profile is defined under the SAML 2.0 Profiles specification. In a web browser-based SSO system, the flow can be started by the user either by attempting to access a service at the service provider, or by directly accessing the identity provider itself.

The OpenSAML 2.6.4 library performs hostname verification. You can disable the hostname verification for testing purposes, by starting the server using the following command. However, note that this should be used for testing purposes and is not recommended in a production environment.

sh wso2server.sh -Dorg.opensaml.httpclient.https.disableHostnameVerification=true

To navigate to the federated authenticators configuration section, do the following.

  1. Sign in. Enter your username and password to log on to the Management Console
  2. Navigate to the Main menu to access the Identity menu. Click Add under Identity Providers.
    For more information, see Configuring an Identity Provider.  
  3. Fill in the details in the Basic Information section. 

You can configure the following federated authenticators by expanding the Federated Authenticators section followed by the required subsections.

 

  1. Expand the SAML2 Web SSO Configuration form. The following appears.
  2. Fill in the following fields where relevant. The * indicates required fields.

    FieldDescriptionSample value
    Enable SAML2 Web SSOSelecting this option enables SAML2 Web SSO to be used as an authenticator for users provisioned to the Identity Server.Selected
    DefaultSelecting the Default checkbox signifies that SAML2 Web SSO is the main/default form of authentication. This removes the selection made for any other Default checkboxes for other authenticators.Selected
    Identity Provider Entity IdThis is basically the entity Id of the identity provider you are configuring. It must be unique among identity providers, for example, you cannot configure another identity provider with this same value.https://idp.example.org/idp/shibboleth
    Service Provider Entity IdThis is the entity Id of the Identity Server. This is useful when differentiating between tenants. This can be any value but it is the value that should be configured in the identity provider to communicate with the Identity Server. So when configuring the Identity Server as a service provider in the identity provider side, this is the value to be configuredwso2is
    SSO URLThis is the URL that you want to send the SAML request to. It should have this format: https://(host-name):(port)/acs.

    https://localhost:8443/idp/profile/SAML2/Redirect/SSO

    Enable Authentication Request SigningSelecting this checkbox enables you to sign the authentication request. If this is enabled, you must sign the request using the private key of the identity provider.Selected
    Enable Assertion EncryptionThis is a security feature where you can encrypt the SAML2 Assertions returned after authentication. So basically, the response must be encrypted when this is enabled.Selected
    Enable Assertion Signing

    Select Enable Assertion Signing to sign the SAML2 Assertions returned after the authentication. SAML2 relying party components expect these assertions to be signed by the Identity Server.

    Selected
    Enable LogoutSelect Enable Single Logout so that all sessions are terminated once the user signs out from one server.Selected
    Logout URL

    You can enter a custom Logout URL if you selected Enable Logout. If you do not enter anything here it will simply return to the SSO URL you specified. This is the URL that the logout request is directed to when the user attempts to log out.

    To do this through the configuration file, open the <IS_HOME>/repository/conf/security/authenticators.xml file and add the following parameters under the <SSOAuthenticator> configuration tag.

    <Parameter name="LogoutSupportedIDP">true</Parameter>
    <Parameter name="ExternalLogoutPage">EXTERNAL_LOGOUT_PAGE_URL</Parameter>
    https://localhost:8443/idp/samlsso/logout
    Enable Logout Request SigningSelecting this checkbox enables you to sign the logout request.Selected
    Enable Authentication Response Signing

    Select Enable Authentication Response Signing to sign the SAML2 responses returned after the authentication.

    Selected
    Signature Algorithm

    Specifies the ‘SignatureMethod’ algorithm to be used in the ‘Signature’ element in POST binding and “SigAlg” HTTP Parameter in REDIRECT binding. The expandable Signature Algorithms table below lists the usable algorithms and their respective URIs that will be sent in the actual SAMLRequest.

    Default value is RSA with SHA1.
    Digest Algorithm

    Specifies the ‘DigestMethod’ algorithm to be used in the ‘Signature’ element in POST binding. The Digest Algorithms table below lists the usable algorithms and their respective URIs that will be sent in the actual SAMLRequest.

    Default value is SHA1.
    Attribute Consuming Service IndexSpecifies the ‘AttributeConsumingServiceIndex’ attribute.By default this would be empty, therefore that attribute would not be sent unless filled.
    Enable Force AuthenticationEnable force authentication or decide from the incoming request. This affects ‘ForceAuthn’ attribute.Default value is As Per Request.
    Include Public CertificateInclude the public certificate in the the request.Selected by default.
    Include Protocol BindingInclude ‘ProtocolBinding’ attribute in the request.Selected by default.
    Include NameID PolicyInclude ‘NameIDPolicy’ element in the request. Selected by default.
    Include Authentication ContextInclude a new ‘RequestedAuthnContext’ element in the request, or reuse from the incoming request.Default value is Yes.
    Authentication Context Class

    Choose ‘AuthnContextClassRef’ element to be sent. Authentication Context Class table below lists the usable classes and their respective URIs that will be sent in the actual SAMLRequest.

    Default value is “PasswordProtectedTransport”.
    Authentication Context Comparison LevelChoose the Requested Authentication Context ‘Comparison’ attribute to be sent. Default value is “Exact”.
    SAML2 Web SSO User Id LocationSelect whether the User ID is found in 'Name Identifier' or if it is found among claims. If the user ID is found among the claims, it can override the User ID Claim URI configuration in the identity provider claim mapping section.User ID found among claims
    HTTP BindingSelect the HTTP binding details that are relevant for your scenario. This refers to how the request is sent to the identity provider. HTTP-Redirect and HTTP-POST are standard means of sending the request. If you select As Per Request it can handle any type of request.HTTP-POST
    Additional Query ParametersThis is necessary if you are connecting to another Identity Server or application. Sometimes extra parameters are required by this IS or application so these can be specified here. These will be sent along with the SAML request.paramName1=value1
     Click here to expand for more information on security algorithms.

    The following table lists out the security algorithms and their respective URI.

     Click here to expand for more information on digest algorithms.

    The following table lists out the digest algorithms and their respective URI.

     Click here to expand for more information on authentication context classes.

    The following table lists out the authentication context classes and their respective URI.

    Authentication context class nameAuthentication context class URI
    Internet Protocol urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
    Internet Protocol Password urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword
    Kerberosurn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
    Mobile One Factor Unregistered urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorUnregistered
    Mobile Two Factor Unregisteredurn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered
    Mobile One Factor Contract urn:oasis:names:tc:SAML:2.0:ac:classes:MobileOneFactorContract
    Mobile Two Factor Contracturn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
    Passwordurn:oasis:names:tc:SAML:2.0:ac:classes:Password
    Password Protected Transporturn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    Previous Session urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
    Public Key X.509urn:oasis:names:tc:SAML:2.0:ac:classes:X509
    Public Key PGP urn:oasis:names:tc:SAML:2.0:ac:classes:PGP
    Public Key SPKI urn:oasis:names:tc:SAML:2.0:ac:classes:SPKI
    Public Key XML Digital Signatureurn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig
    Smartcard urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
    Smartcard PKIurn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
    Software PKI urn:oasis:names:tc:SAML:2.0:ac:classes:SoftwarePKI
    Telephonyurn:oasis:names:tc:SAML:2.0:ac:classes:Telephony
    Telephony (Nomadic)urn:oasis:names:tc:SAML:2.0:ac:classes:NomadTelephony
    Telephony (Personalized) urn:oasis:names:tc:SAML:2.0:ac:classes:PersonalTelephony
    Telephony (Authenticated) urn:oasis:names:tc:SAML:2.0:ac:classes:AuthenticatedTelephony
    Secure Remote Password urn:oasis:names:tc:SAML:2.0:ac:classes:SecureRemotePassword
    SSL/TLS Certificate­Based Client Authenticationurn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
    Time Sync Token urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken
    Unspecifiedurn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

    Configure ACL URL in a production environment

    The default assertion consumer URL that is sent with the SAML request includes the local domain and default port. In a production environment, you may need to change the assertion consumer URL. To do this, follow the steps below:

    1. Open the application-authentication.xml file found in the <IS_HOME>/repository/conf/identity folder.
    2. Add the following property and update the assertion consumer URL as required.

      <AuthenticatorConfig name="SAMLSSOAuthenticator" enabled="true">
      	<Parameter name="SAMLSSOAssertionConsumerUrl">https://localhost:9443/commonauth</Parameter>
      </AuthenticatorConfig>

Configure ACL URL in a production environment

The default assertion consumer URL that is sent with the SAML request includes the local domain and default port. In a production environment, you may need to change the assertion consumer URL. To do this, follow the steps below:

  1. Open the application-authentication.xml file found in the <IS_HOME>/repository/conf/identity folder.
  2. Add the following property and update the assertion consumer URL as required.

    <AuthenticatorConfig name="SAMLSSOAuthenticator" enabled="true">
    	<Parameter name="SAMLSSOAssertionConsumerUrl">https://localhost:9443/commonauth</Parameter>
    </AuthenticatorConfig>

Configuring hostname verification

In previous releases, SAML Single-Logout (SLO) requests for service providers were initiated without hostname verification which can impose a security risk. From IS 5.2.0 release onwards, certificate validation has been enforced and hostname verification is enabled by default. If you want to disable the hostname verification, configure the following property in the <IS_HOME>/repository/conf/identity/identity.xml file under the Server\SSOService tag. 

<SLOHostNameVerificationEnabled>false</SLOHostNameVerificationEnabled>

Note: If the certificate is self-signed, import the service provider's public key to the IS client trust store to ensure that the SSL handshake in the SLO request is successful. For more information on how to do this, see Managing Keystores with the UI in the WSO2 Product Administration Guide.

Related Topics
  • No labels