...
If you don't know why you would need this feature, then you don't need it. Leave the default settings alone and ignore them.
| Note |
|---|
Since the primary use case for this feature involves the forwarding or delegation of signed assertions, the XML is passed along unmodified from the issuer. As a result, although some security checking has been performed prior to caching, the data itself is left alone. Attribute filtering is not reflected in the results. |
When In order for the export to be functional, the exportLocation and exportACL properties must be set for the relevant application's <Sessions> element.
Then, when instructed to do so for a request (via the exportAssertion content setting), the application will be given a header or variable called Shib-Assertion-Count with the number of assertions that are available.
The URL to query for each assertion is passed in an individual header or variable named Shib-Assertion-NN, where NN is the two-digit sequence number of the assertion(01, 02, etc). Performing a GET on that location will result in the assertion, with a MIME type of "application/samlassertion+xml".Note that in order for export to occur, the exportLocation and exportACL properties must be set for the relevant application's <Sessions> element
| Note |
|---|
Since the primary use case for this feature involves the forwarding or delegation of signed assertions, the XML is passed along unmodified from the issuer. As a result, although some security checking has been performed prior to caching, the data itself is left alone. Attribute filtering is not reflected in the results. |
Distributed Scenarios
In some cases, it's possible for the code that needs to perform the retrieval to be running on a different host from the SP itself. One such scenario would be a Java container fronted by Apache, such that Apache and the SP run separately from the Java container. The SP doesn't provide any real way of "securing" the retrieval step.
...