When acting as a Service Provider and using CA SSO as the SAML Endpoint consuming Assertions, a good thought needs to be given in terms of how do we retain attributes OR do we need to retain attributes OR how long do we need to retain attributes.
Currently there are two different ways CA SSO Federation capability can present Attributes from SAML Assertion to End Application.
- Using HTTP Header Redirect Mode.
- Persist Session Variables.
Both of these options does the same end goal. How is then one different from the other. I would not say that one approach is superior OR better than the other, it really depends on the context of design and requirement, one would gain the upper hand in any given situation. For me something HTTP Header Redirect works good, at other times Persist Session Variables.
|HTTP Header Redirect Mode||Persist Session Variables|
|Does not need a Session Store||Needs a Session Store|
|Header from Assertion are Only available on the first redirect from WAOP to TARGET. Lost thereafter.||Header from Assertion are Persisted in the Session Store. As long as SMSESSION is valid and those values can be set as a Header from Session Store. Lost after SMSession Expires.|
|Quick time to delivery implementation and faster processing.||Takes time to implement. A tad slower in processing as it involves write and read.|
|Does not have ability to set any SM_ headers.||Does have the ability to overwrite default SM_ headers.|
|No Realm level persistence needed.||May need Realm Level Persistence based on the Response configured on Policy Server.|
|Redirect Mode has to be "HTTP Header"||Redirect Mode can be simple "302 Redirect"|
|Pass Assertion Data as HTTP Headers to Relying Party Applications - CA Single Sign-On - 12.52 SP1 - CA Technologies Docu…||Authentication Schemes - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation|
A good use case for review : Know How : SMSAMLDATA Plugin and SM_ Headers to set some context.