Forum Discussion
NimbostratusAPM Federated authentication for Microsoft DreamSpark?
Hi all,
Has anyone had any experiences setting up federated / SAML authentication for Microsoft's academic software distribution service DreamSpark? We're using APM 11.3 for Office 365 federation via the iApp for the service, and that is working well, but I think I would need to manually create configuration for DreamSpark as I can't find an iApp. DreamSpark seems to be very similar in terms of SAML requirements, at least the documentation refers to using Shiboleth as the IdP, so I assume we can just use our APM in it's place. My main query I suppose is regarding setting up a SAML configuration without an iApp...
https://www.dreamspark.com/Default.aspx
A firm call Kivuvu take care of the SP role for the DreamSpark service it seems, here is their Shiboleth setup guide for the service
ftp://ftp.kivuto.com/support/outgoing/ELMS_Shibboleth_User_Verification_Customer_Implementation_Guide_en.pdf
Any experience of DreamSpark federation with APM, or experience with setting up SAML iDP configurations from scratch without an iApp would be really appreciated!
Many Thanks,
Gavin
2 Replies
- Kevin_Stewart
Employee
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.
-
The External SP connector should be created, if possible, completely from imported metadata. This will come from the Kivuto SP config.
-
The IdP service's "IdP Entity ID" is generally the HTTPS URI of the APM IdP VIP (and URI if required).
-
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.).
-
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.
-
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.
-
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.
-
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.
-
Gavin_Connell-OThanks Kevin, that's really useful. I'll drill into my current SAML config and try to get familiarized. I'll be able to set this up in trial before unleashing it to users so there will be some scope for feeling my way forward hopefully. Any progress I make I'll put here on this thread.
Meanwhile if anyone else is considering or using APM for DreamSpark, get in touch!
Cheers,
Gavin
