Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Nov 05, 2013

No specific experience with DreamSpark or Kivuto, but take a look at the APM SAML configuration that you have now (for O365). I want to point out some common characteristics of an APM SAML IdP configuration.

 

  1. The External SP connector should be created, if possible, completely from imported metadata. This will come from the Kivuto SP config.

     

  2. The IdP service's "IdP Entity ID" is generally the HTTPS URI of the APM IdP VIP (and URI if required).

     

  3. The IdP service's "Assertion Settings" section is used to define what subject identity value is sent in the assertion. This is entirely dependent on what the SP needs. The Assertion Subject Type is a nameid-format specifier. The SP may be looking for a specific specifier (ex. unspecified, email, upn, etc.). The Assertion Subject Value is an APM session variable that is generated during IdP access policy evaluation (the logon process) and is what is sent as the subject identity value. For instance, if you're authenticating the user with a form and AD auth, the session.logon.last.username session variable will contain the users submitted name. Again, this is dependent on what the SP is expecting (ex. sAMAccountName, userPrincipalName, emailAddress, etc.).

     

  4. The IdP service's "SAML Attributes" section is where you define additional attributes to be included in the assertion. These can be static values, values derived from AD/LDAP querys (ex. memberOf), and anything else the SP might need.

     

  5. The IdP service's "Security Settings" section is where you define the certificate and private key that the IdP will use to sign (and potentially encrypt) outgoing assertions.

     

  6. Once the IdP configuration is created, you can export its metadata and import that to the SP. The metadata files will contain the respective public certificates from each entity to build the cryptographic between them.

     

  7. An IdP configuration is considered an SSO object in APM, so your APM profile should include whatever client side authentication mechanisms you need, plus this SSO object. For "SP-initiated" SAML, the client will go to the SP, get redirected to the IdP with an authentication request, authenticate to the IdP, and then get redirected back to the SP with a signed assertion. If the cryptography is correct, and the SP can consume and validate the assertion, then you should be good to go.