Symantec Access Management

We are currently trying to integrate a .NET application that was deployed on WIndows Azure with SiteMinder. The sample application is developed by the developer using the instructions from the following link:

http://www.cloudidentity.com/blog/2014/02/20/ws-federation-in-microsoft-owin-componentsa-quick-start/

On a high level, the application requires an IDP Metadata URL. Once you try to access this app, it generates the request to the IDP using the Metadata URL defined for a Token and then allow the user into the application. The above link uses ADFS. If we update the Link to OKTA Metadata URL ( another Product that provices Cloud based SSO), we are able to log into application. The app is configured to basically accept any WS FED Token from an AP and then allow the user into the application.

However when we try to integrate with SM with SiteMinder being the Account Partner, it fails. So ca

The application works fine when we try to integrate with ADFS or OKTA as Account Partner , other WAM Products. Only we see this issue when trying to have SiteMinder as the Account Partner.

Can we integrate a App on Azure Cloud that is configured to accept WS-FED Token with SiteMinder directly( SiteMinder being the Account Partner and then posting the WSFED token to the application directly? PLEASE NOTE THAT THERE IS NO ADFS HERE.??

The Run book provided mentions using ADFS and SiteMinder but PLEASE UNDERSTAND THAT WE ARE NOT USING ADFS HERE.  We are actually directly posting the token to the sample app on the Azure Cloud. I'm still trying to make sense here as the sample application allows the user ( i'm thinking it is using Claim based login as per my understanding ) when it gets the token from ADFS or Okta  but not with SiteMinder.

If SiteMinder is providing the WSFED-Token as per standard it should be able to accept it and allow the user.

Thanks

Hi AnandKaturi,

Just checking, if you have referred to the following runbook which provides the necessary steps to configure the federation partnership to achieve SSO (Single-Sign-On) between CA SiteMinder 12.52, acting as the Identity Provider (IDP), and Microsoft Azure acting as the Service Provider (SP).:

SAP Portal Services

Thanks Wonsa3. We were able to get past this. We are not using any ACS in the flow. We are actually POSTING the WSFED token directly to the application and the app is developed to use the OWIN framework to validate the WS -FED TOken and then allow the user into the application.

But this is where we are stuck currently:

1. Federation Gateway is in .company1.com) where SM is acting as IP and submitting as WS FED Token to the RP i.e. the Application on Azure.

2. When you try to access the application, it redirects you to the SiteMinder login page ( The Authentication URL is protected with this login page) as it supposed to correctly.

3. Once I submit the credentials, the log shows that i’m authenticated and authorized successfully. Since we have a Cookie Provider ( .company.com), after successful login, I see the browser going to the cookie provider(https://company.com/SmMakeCookie.ccc?SMSESSION=)

4. However my browser gets stuck on this page and I see a 404 on Fiddler ( Fiddler attached as attachment).

The Policy Server log shows that I’m authenticated/Authorized for the redirect.jsp successfully as seen in the The only error I see is a 404 error on Fiddler for the Auth URL in the IIS logs and I don’t see anything else in the policy server or agent. The CP is up and running and i can see from the logs that it is creating cookie in the CP domain successfully.

Any suggestions here?

As the initial issue and the current one is different now can you share the solution to your initial issue and create a new post for the new issue you are encountering?

I can see this can become a very lengthy chain of conversation.

Hi @AnandKaturi,

Confirm if .ccc is included in cookie provider's ACO -- IgnoreExt. Also, please let us know the cookie provider's webagent version and check the agent log and trace corresponding to the error.

Even though cookie provider within Federation environment may work, this configuration is not supported due to some limitations.

Yes. CookieProvider configurations are set as mentioned. The Agent version is 12.52.0.142. That is what the response we got from the Support. However we made some interesting observations as follows:

• The SP Initiated flow was throwing the error all the time ( Click the app URL and it automatically redirects to SM login page with query strings wtrealm,wctx ).
• The IDP-initiated flow was working fine ( https://sps-gateway/affwebservices/public/wsfedsso?wa=wsignin1.0&wtrealm=<RPID>
• When we appended the "Wctx" query string to the IDP initiated URL, we were able to reproduce the issue. For our SPIDinitiated URL, we were getting the wctx value as "WsFedOwinState%3dmb7vHJkDcugAUEPihgagh agahgrgigagar gagh agarghaga........."
• However when we have the "Wctx" querystring parameter value shortend ( WsFedOwinState%3dmb7vHJkDcugAUEP), i was able to login successfully.

SO not sure why the full value for WCTX is causing the Cookieprovide throw 400 error.

Hi AnandKaturi,

We suspect there might be limitation on the query string size.

Have you tried this IDP-initiated request with different internet browsers?

Compare the initial request with the request that arrive at cookie provider for both IDP and SP-initiated request. Check on the query string size.