Hubert,
Thank you so much for breaking down each question and answering them in details. I still feel very frustrated about the two issues with Partnership Federation. If my understanding is correct then moving away from Legacy FSS to Partnership Federation model provides a few excellent bells and whistles but will also take away a few key strategic features of SiteMinder federation capabilities:
**Partnership Federation requiring "deactivate" to make changes - At times our SAML SP partners would introduce new application function/features which would require us to modify/add SAML attributes or other SAML param changes. With our Legacy FSS we could make this configuration change to the SAML SP object and "Flush" the cache in the Admin UI and within few minutes the SAML SP updates are pushed through to all three of our policy servers in production and during this entire process no SSO service interruption is experienced for this SAML SP. I just feel that service outage, even planned is the one thing that any organization would want to avoid at all cost.
**No "Application URL" parameter for custom AGP - Did CA provide a reason for removing this critical feature which allows CA customers to design robust SAML SSO configuration patterns for their complex federation SSO architecture? As previously explained, being able to specify individual URL/service endpoints for each of the SAML SP partners allows us to dynamically deploy new SAML SP partners without requiring code changes to either the AGP or the sample JSP pages.
I would like to look a little bit more into your suggestion about utilizing the sample JSP page from the WAOP as a possible "workaround". Can you explain to me how we can specify or invoke a specific JSP page for each different SAML SP object? Below is one of our typical SAML outbound SSO flow to an SP partner:
1) User login to IDP web portal and upon successful authentication, web agent creates a set of HTTP headers including "sm_userid" and "user_pin" http header.
2) User clicks on an IDP initiated SSO URL - - - > /affwebservices/public/saml2sso?SPID=SP1
2) FSS redirect the browser to Application URL resource
3) Application URL resource reads the "sm_userid" and "user_pin" request header values and then POST these two values including SMPORTALSTATE values to SAML2SSO.
4) FSS passes the "sm_userid" and "user_pin" values to custom AGP
5) AGP reads the "agp.properties" file
6) agp.properties file:
vendor.attributes=PartnerId,InsuredId
attr.PartnerId.name=Customer_code
attr.PartnerId.nameFormat=urn:oasis:names:tc:SAML:2.0:attrname-format:basic
attr.PartnerId.source=STATIC
attr.PartnerId.sourceDetail=company_abc
attr.PartnerId.url=none
attr.InsuredId.name=InsuredId
attr.InsuredId.nameFormat=urn:oasis:names:tc:SAML:2.0:attrname-format:basic
attr.InsuredId.source=Service
attr.InsuredId.sourceDetail=account_id
attr.InsuredId.url=https://api-service.company.com.com/ces/v2.0/member/{0}/family
attr.InsuredId.replaceSourceDetail=true
7) AGP makes calls to API service endpoint from the properties file to retrieve additional attributes from external database
8) AGP generate SAML assertion