Hi,
we developed a SSO plugin for our software where we 'd act as Service provider and we’d initiate the SSO process.
One of our Customers now insists on doing everything using Federation Metadata. We were provided an URL to their sample federation metadata.Following this post http://www.componentspace.com/Forums/35/SAML-Metadata-Generation-and-Consumption I generated a saml.config file using this xml. In another post here I read you recommend generating the saml.config manually instead of programmtically reading the Federation Metadata provided via URL.
However I still have some questions:
- the file does not contain a certificate reference or similar. Does this have to distributed manually to us or is it possible to include this somehow in the federation metadata? The customer wants to use a public key certificate only.
- if we generate a saml.config once instead of doing the configuration programmatically using the supplied metadata url - what would happen, when the certificate file has to be replaced (e.g. when it expires)?
- in manual configurations the AD FS would have to be configured in order to accept our requests. How is this done otherwise, do we generate a Federation XML ourselves specifying AssertionConsumerServiceUrl etc.? What would be the minimum requirements regarding the Federation Metadata Xml we supply so an AD FS (of our customer) would to be able generate a relying party trust for our service?
- how would I be able to include the accepted / required claims attributes in the Federation Metadata I supply so the customer can add the appropriate mappings - can I do this using the supplied export utitlity? If not how?
Your help and advice are very much appreciated. Thanks in advance
Janet
Hi Janet
There are a couple of options for handling the SAML metadata supplied by the IdP. You can either run the ImportMetadata utility to import the metadata into your saml.config or you can manually edit the file.
Generally the SAML metadata will include the X.509 certificate. This is the standard way to communicate which certificate is being used. If the certificate is not included in the metadata then the IdP must supply this to you some other way (eg send you the .CER file).
Once the certificate expires you will need to update the saml.config to specify the new certificate.
For ADFS, you can either define a relying party by manually entering the information (ie names and URLs) or by importing the SAML metadata.
You can generate SAML metadata from your saml.config using the ExportMetadata utility.
Currently we don’t support specifying required SAML attributes (ie claims in ADFS terminology) through saml.config and the ExportMetadata utility. You would have to add this manually to the SAML metadata to supply to ADFS.
You’re welcome to contact me by email (support@componentspace.com) mentioning this topic. If you can supply your saml.config and the partner IdP’s metadata I can take a look and provide more specific assistance. Similarly, I can provide an example of how to update your metadata to specify claims.
Hi,
thanks a lot, I had the impression of the certificate being including in the metadata file, but the generated saml.config did not include it.
I will contact you by support email.
Regards,
Janet
The certificate can be included in the SAML metadata and this is what ADFS does.
The ImportMetadata tool saves the certificates contained in the SAML metadata as .CER files.
The saml.config includes “TODO” instructions for incorporating the appropriate .CER file into the SAML configuration.