Symantec Access Management

  • 1.  SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 10, 2018 03:08 PM

    Hello Folks,

     

    We are in our planning process of upgrading from our current r12.52 to r12.8 and we have a few questions specifically regarding the "hopefully" improved and changes on the r12.8 Federation Partnership model.

     

    Two years ago we upgraded from r12.0 to r12.52 and were introduced to the new Federation Partnership model for creating Federation SSO configurations.  Right away we noticed a major show stopper which CA acknowledge as a bug.  This show stopper issue with the r12.52 Federation Partnership is the missing "federation application URL" field from within the Admin UI when utilizing the custom Assertion Generator Plugin.

     

    With the Legacy Federation you have the option to specify the "Application URL" to redirect the browser to an application where we would collect additional user attribute/parameters which will then be passed back to the custom assertion generator plugin (AGP).  With the Partnership Federation we don't seem to have that option within the Admin UI when creating federation partnership configuration (please see attached images).

     

    The second question that we want to know is, with the R12.8 Partnership Federation model, do we still need to "Deactivate" the partnership in order to modify or make configuration changes to that partnership?  At times we are required to make configuration changes to an existing SAML service provider in our Legacy Federation configuration, but this change does not require any downtime.  With the Partnership Federation, it requires you to "Deactivate" a particular federation partnership in order to make any changes to it, this will cause downtime.

     

    Also, the r12.52 Admin UI seemed quite slow in performance when navigating through the Partnership Federation, has this performance changed with later releases?

     

    Much thanks in advance!

     

    Duc,



  • 2.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 10, 2018 05:02 PM

    Duc dmt953

     

     

    QuestionsAnswers

    Two years ago we upgraded from r12.0 to r12.52 and were introduced to the new Federation Partnership model for creating Federation SSO configurations.  Right away we noticed a major show stopper which CA acknowledge as a bug.  This show stopper issue with the r12.52 Federation Partnership is the missing "federation application URL" field from within the Admin UI when utilizing the custom Assertion Generator Plugin.

     

    With the Legacy Federation you have the option to specify the "Application URL" to redirect the browser to an application where we would collect additional user attribute/parameters which will then be passed back to the custom assertion generator plugin (AGP).  With the Partnership Federation we don't seem to have that option within the Admin UI when creating federation partnership configuration (please see attached images).

    In the partnership model you are correct there is no provision to define Application URL.

     

    That being said many customers have implemented passing additional attributes/parameter to Custom AGP using JSP pages. There is a sample JSP page which is shipped with WAOP code.

     

    We protect the JSP page. Thus inorder to access the JSP one has to be authenticated. Once Authenticated the JSP page can read attributes off the query string and POST it to saml2sso endpoint, which would inturn pass it to the Custom AGP.

    The second question that we want to know is, with the R12.8 Partnership Federation model, do we still need to "Deactivate" the partnership in order to modify or make configuration changes to that partnership?  At times we are required to make configuration changes to an existing SAML service provider in our Legacy Federation configuration, but this change does not require any downtime.  With the Partnership Federation, it requires you to "Deactivate" a particular federation partnership in order to make any changes to it, this will cause downtime.Yes. The only way to make updates is to deactivate. That said, in R12.8, if you need to update the signing certificate, that can be done without having to deactivate the partnership.
    Also, the r12.52 Admin UI seemed quite slow in performance when navigating through the Partnership Federation, has this performance changed with later releases?There was bug in the WAM UI federation partnership. The bug was as we traverse every tab, WAM UI was generating calls to User Directory. This slowed down the speed of traversing tabs in the partnership. This has been fixed and vetted. R12.8 WAMUI Federation Partnership is much faster.


  • 3.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 10, 2018 07:04 PM

    Hubert, thank you for your quick response.

     

    I think this may be a serious show stopper for us.  We utilized the custom AGP heavily for our dozens of different SAML service provider partners.  Each SAML service provider partner has different user data requirements from the SAML payload and therefore utilized the "Application URL" parameter to redirect the browser to a specific JSP/API to collect user data and then POST it to the AGP based on each specific SAML SP partner's user data requirements.  With our current design, we have one custom AGP deployed which consumes the data input from multiple different application sources (Application URL) depending upon which SAML SP partners is being invoked.  This design allows us to deploy only one custom AGP and the flexibility of passing different user data to the AGP for each different SAML SP partners by redirecting the browser to a specific application/API via the "Application URL" configuration parameter.

     

    Regarding the requirement to "Deactivate" the federation partnership in order to make changes to it, what is your thought on this, Hubert?  I think that this is a major step "backward" in comparison to the Legacy FSS because we should be able to make changes to an existing federation partner configuration without needing to schedule for a service outage window.

     

    The Partnership Federation model does have a lot more federation features available compared to the Legacy FSS along with the ability to specify multiple SAML signing certificates from remote SAML IDPs, which is a huge plus when it comes to managing certificate expirations with remote IDP partners, but it looks like there are some significant drawbacks with the Partnership Federation model in comparison to the Legacy Federation services model.

     

    The big question here is, do you know if CA has any plans to eventually remove the Legacy Federation model with future releases?



  • 4.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 13, 2018 12:34 PM

    Duc dmt953

     

    Here are my thoughts

     

    QuestionsThoughts
    I think this may be a serious show stopper for us.  We utilized the custom AGP heavily for our dozens of different SAML service provider partners.  Each SAML service provider partner has different user data requirements from the SAML payload and therefore utilized the "Application URL" parameter to redirect the browser to a specific JSP/API to collect user data and then POST it to the AGP based on each specific SAML SP partner's user data requirements.  With our current design, we have one custom AGP deployed which consumes the data input from multiple different application sources (Application URL) depending upon which SAML SP partners is being invoked.  This design allows us to deploy only one custom AGP and the flexibility of passing different user data to the AGP for each different SAML SP partners by redirecting the browser to a specific application/API via the "Application URL" configuration parameter.

    Your concerns are valid, in that, you do not see a 1:1 map between Legacy Object Definition and Partnership Object Definition; furthermore we are missing a element which is key to your success.

     

    I still strongly think it is still very much doable without the ApplicationURL definition within the Partnership.

     

    The URL to intiate the flow would be as follows, may be that is the only thing that changes.

     

    https://FQDN/affwebservices/customjsp/SP1.jsp

    https://FQDN/affwebservices/customjsp/SP2.jsp

    https://FQDN/affwebservices/customjsp/SP3.jsp

     

    SP1.jsp collects pertaining information and posts to saml2sso with SPID of SP1 Partnership.

     

    SP2.jsp collects pertaining information and posts to saml2sso with SPID of SP2 Partnership.

     

    SP3.jsp collects pertaining information and posts to saml2sso with SPID of SP3 Partnership.

    Regarding the requirement to "Deactivate" the federation partnership in order to make changes to it, what is your thought on this, Hubert?  I think that this is a major step "backward" in comparison to the Legacy FSS because we should be able to make changes to an existing federation partner configuration without needing to schedule for a service outage window.

    I think I see it in a different perspective. When doing a production change, if there is active traffic flow then different users end up seeing different behaviours until everything resync up.

     

    In Legacy Model, we are at the mercy of when WAOP / Policy Server caches pick up the changes being doing on a live Legacy Object on the Policy Server. There have been times where customers have had to do unplanned restarts on WAOP or Policy Server inorder to sync caches; simply because their change did not account any outages OR cache update discrepancies. We have had customer stating otherwise, why did CA not inform us that we have to restart to resolve sync problem (Cache Sync can occur due to varied factors; but the quickest way to resolve is restart).

     

    In partnership model deactivating / activating the partnership ensure that all caches are updated (Cache updates are enforced onto Policy Server and WAOP). It also accounts for the fact that in change management we are clearly accounting for a downtime during a production change, when we expect no live traffic to flow. Thus giving users a consistent experience during and after the change. Most importantly we are not leaving the change upto chance / uncertainty. Thus the feature itself was introduced with Customer feedback. Now CA is telling customers what is the best method to do it, so that Customers do not have baggage (issues) after the change is completed.

    The Partnership Federation model does have a lot more federation features available compared to the Legacy FSS along with the ability to specify multiple SAML signing certificates from remote SAML IDPs, which is a huge plus when it comes to managing certificate expirations with remote IDP partners, but it looks like there are some significant drawbacks with the Partnership Federation model in comparison to the Legacy Federation services model.I do see that how important the application URL is to you and hence that 1 VS multiple goodies, the 1 fairs / weighs quite high. But once we find a working solution which replaces the Application URL and we start using Partnership, am sure over time you'd feel the benefits.

    The big question here is, do you know if CA has any plans to eventually remove the Legacy Federation model with future releases?

    May be, I don't know yet. But look at what happened with FSS UI VS WAM UI. So history states the possibilities are high, just a matter of time, when.


  • 5.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 13, 2018 11:12 PM

    Duc dmt953

     

    We don't have to deactivate and make the changes at the same time. 

     

    Here is a best approach which will give you time to verify changes, less error prone, low risk, lowest down time and in the snap of a finger roll back / roll forward. It will also account for the concern that was raised in terms of duration of down time. At the same time making sure you have a squeaky clean change.

     

    1. You can always create a new "INACTIVE" partnership with a version controlling name with new changes, parallel to the "ACTIVE" partnership. You can create the "INACTIVE" Partnership well before the cutover. On the day when you really want to introduce the new change, all you need to do is the following.
    2. Deactivate the "ACTIVE" Partnership.
    3. Wait for 30 - 60 seconds. The reason I say wait, is for the deactivation to sync through the Policy Server and WAOP Cache. What I also recommend is doing repeated tests of the URL from the browser as soon as we deactivate. As soon as I get an error I know the Cache's have been refreshed. When deactivated, it is as good as the SPID (if you are acting as IdP) / IdPID (if you are action as SP) cannot be found in Cache (Object will be loaded in Cache, but marked as unusable).
    4. Activate the "INACTIVE" Partnership. You are ready to rock and roll with the new changes. Cache's both Policy Server and WAOP will be updated immediately.
    5. In the event, you need to roll back, just follow Steps [1] to [4]. In the event, you need to take corrective action and roll forward at a future date, just follow Steps [1] to [4].
    6. Word of Caution, both partnerships cannot be ACTIVE at the same time, only one will be ACTIVE. They can be INACTIVE at the same time.
    7. After a soaking period, you can go in and delete the no longer needed INACTIVE partnership.

     

    Example (R12.8 WAM UI)

     

    Hope this helps.

     

    Regards

    Hubert



  • 6.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 14, 2018 01:25 AM

    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



  • 7.  Re: SiteMinder upgrade r12.52 to r12.8 - Legacy Federation V.S Federation Partnership

    Posted Aug 15, 2018 10:00 AM

    Duc dmt953

     

    I think you have everything configured. All that needs to be done is change the link on IdP Web Portal.

     

    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 link i.e. Application URL to a specific JSP Page for each Service Provider.

    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