I was looking at an issue for a Customer in Federation.
- Customer is Service Provider.
- WebAgent (IIS) and WAOP (ServletExec) is on the same machine; hence they use same the same ACO (same WebAgent.conf).
- Customer is using FQDNs to separate traffic inbound (more so give a personalized feeling to IdP using customer name in FQDN / URL) to access Services, however the landing pages are same.
- There are links on the landing page which gets populated at run time to forward end-user request ahead.
- They have multiple FQDN mapping to their WA/WAOP Server.
- The intend to use SSL Certificate which is a Global wildcard certificate issued for “*.sp.com”.
E.g. FQDNs on WA/WAOP Server.
Therefore we adopted to use Agent Identities using AgentName ACO parameter as we do in WebAgent world. We know we could use AgentName parameter for Agent to FQDN mapping. Thus our configuration looks like below.
Agent to Policy Domain Mapping
- wa_xyz,xyz.sp.com --> Policy Domain xyz --> Realm xyz --> SAML Auth Scheme xyz --> UD1.
- wa_abc,abc.sp.com --> Policy Domain abc --> Realm abc --> SAML Auth Scheme abc --> UD1.
Agent ACO Mapping
DefaultAgentName : wa_abc.
AgentName : MutliValue
The issue that we are facing is that; it looks like WAOP does not honor AgentName parameter. WebAgent does honor this logic correct. Once the request handed to WAOP, it simply tries to validate using defaultagentname and the entire solution falls apart.
After searching about we found an article on Support.
Therefore the current solution on WAOP is restrictive in the fact that it could be segregated only on basis of URI. What would be good to have would be also include segregation based on FQDN thus allowing Virtual Hosting capabilities into WAOP (as it is done via WebAgents).
The alternative may be to use CA Access Gateway (a.k.a Secure Proxy Server). However for the majority of the customer who are on WAOP deployment, this would be a beneficial one to have.