Most of the Identity Provider information requested that is not related to SAML Attributes is listed in the client's SAML Identity Provider Metadata XML file, which can be provided to Swank either as a file or by a publicly accessible URL. Swank prefers receiving the Identity Provider Entity ID and a SAML Identity Provider Metadata XML file from the client administrator to provide a more accurate setup process. If the SAML Metadata is not available, the client administrator needs to provide to Swank these items, at a minimum:

• Entity ID
  • This identifies the Identity Provider to Streaming Server.
• Identity Provider's certificate with public key
  • The Identity Provider's x.509 certificate including only a public key needs to be provided to Swank. One of three kinds of certificates are supported: DER (distinguished encoding rules) binary format certificates without a private key including .CER, .CRT or .DER files; Base-64 PEM (privacy-enhanced electronic email) text format without a private key including .CER, .CRT or .PEM; PKCS#12 (public-key cryptography standards) binary format with a private key including .PFX or .P12 is supplied must also be provided with the password. We strongly suggest against providing Service Provider with a Certificate with a private key. Instead just provide Service Provider with a copy of your Identity Provider Certificate that contains only the public key
• Single Sign-on Service URL
  • The Identity Provider's Single Sign-on URL
• SAML Service Binding
  • The Identity Provider's Single Sign-on SAML service binding. It must be one of:
    • urn:oasis:names:tc:SAML:20:bindings:HTTP-Redirect
    • urn:oasis:names:tc:SAML:20:bindings:HTTP-POST
  • This deals with how the Streaming Server will contact the Identity Provider when a user requests to authenticate using SAML. We prefer urn:oasis:names:tc:SAML:20:bindings:HTTP-POST, if possible, to avoid HTTP GET request length limitations in some browsers.
• Whether or not the Identity Provider is able to sign assertions and authn requests.
  • For best security we prefer that assertions and authn requests be signed using the certificate, but this is not required. This protects against SAML being tampered with and protects Identity Server information as it is transmitted to Streaming Server.