CA SPS Federation Gateway Question

[Adam Rusniak]

Hi all,

 

I have a question regarding using the CA SPS as a Federation gateway.

 

In my use case I have one SPS instance with multiple virtual hosts defined. I have already used the nete:cond type="host" criteria for the entry point to proxy the host header field to the respective backend servers the virtual hosts are defined for.  What is the recommended approach then for only allowing a single one of these virtual hosts to be used for access to the federation servlets?

 

In my case currently I am able to hit the /affwebservices/assertionretriever from all virtual hosts

 

https://federationgateway.example.com/affwebservices/assertionretriever

 

https://virtualhost2.example.com:11443/affwebservices/assertionretriever

 

https://virtualhost3.example.com:12443/affwebservices/assertionretreiver

 

I would like to limit this to only the example virtual host https://federationgateway.example.com/affwebservices/assertionretriever

 

Previously when I have used just Apache and web agent option pack on application server this would be easy to define with the proxypass, proxypassreverse and !proxy rules.

 

I've seen previous discussions where some were setting up multiple instances of SPS to handle multiple nete:conditions but this seems cumbersome for the task.

Each of my virtual hosts are using a separate WebAgent.conf, but would like to handle the rules at the proxy level instead of at the SSO level. I'm guessing there is a simple way to do this and I am overlooking it.

 

Thank you for the help,

 

Adam

[Adam Rusniak]

Any ideas or has anyone run into

this before? Thanks.

[Legacy User]

One of the approaches that I could think of is.....

 

Approach-1

 

On the Policy Server using WAM UI>

Create a HTML Forms Authentication Scheme, the URL in the Authentication Scheme would be a Static Error Page (e.g. https://FQDN/noaccess.html). Now create a AgentGroup (e.g. prot_affwebservices_agentgroup). Now create a realm which protects /affwebservices*. Associate the AgentGroup with realm and associate the authentication scheme with the realm.

 

On the SPS>

Instead of using the generic WebAgent.conf which applies to all VHs; use independent WebAgent.conf under each VH section. Since we have independent WebAgent.conf, we can point to different ACO / Agent Object. Now add all those VH / Agent Objects from where we intend to block /affwebservices* into the AgentGroup.

 

Now Test>

Access from VH which are added to AgentGroup (e.g. prot_affwebservices_agentgroup). User should see https://FQDN/noaccess.html

Access from VH which is not added to AgentGroup (e.g. prot_affwebservices_agentgroup). User should be able to access /affwebservices.

 

 

Approach-2

 

I wish there could be a way to block this at the server.conf layer using a switch i.e. which VH should allow access to WebApps (e.g. like the AuthAzWS VH). I don't think we have any exposed as of now. May this would be an ER.

 

 

Regards

 

Hubert

[Adam Rusniak]

Thanks Hubert! I like your creative thinking with the Authentication Scheme approach. Let me play around with that and see how it comes out.

 

I do also wish this could be handled in the server.conf on the SPS with a switch for allowing individual VH access to those Fed web apps. I think I will open an enhancement request like you mentioned and see if it gets any traction. It seems this would be a pretty common use case. I know CA recommends using a separate instantiation of the SPS if heavy Federated processing is going to occur but for deployments where the SPS is to be viewed as an "access gateway" I would think more folks would run into this.

 

Appreciate the response,

 

Adam

[Legacy User]

Thank You Adam,

 

You'll have my vote on that ER, Yes customers need that flexibility of ensuring which VH allows access to WebApps that we ship. Hardening security and access refers to the ability of blocking access to resource where it needs to be blocked. I see the benefit of allowing SPS-Hosted-WebApps across all VHs. At the sametime I would also like to see the ability to block OR limit SPS-Hosted-WebApps to particular VH. This also refers to the ability of allowing to map WebApps to particular VH e.g. Allow Affwebservices only via VH1.ca.com and Allow sessionassurance only via VH2.ca.com. The ultimate thing would be the ability to manage which VH allows proxy functions e.g. affwebservices only via vh1.ca.com and no proxy using this vh1.ca.com (but proxy would be via some other VH e.g. vh3.ca.com).

 

Regards

 

Hubert

[Adam Rusniak]

CA SPS - Block access to Federated Web Apps on Virtual Host Basis

 

Hey Hubert, thank you again for the reply. I do agree also with the other functionality you have mentioned. Here is the link to the enhancement request I opened. Please feel free to include the additional functionality there, it seems to all tie together into a similar request.

 

Appreciate it,

 

Adam

[Adam Rusniak]

Hey Hubert,

 

Just another note - your method worked great using the auth scheme to redirect to a NO ACCESS page. I was testing other ways  and use cases of doing this redirect as well.

 

I used the same agent group method with the different virtual host agent objects added. I created the domain for protecting affweb.

Created the realm as: /affwebservices

Used any auth scheme: For example basic username / password

Created two rules this time:

First rule:

Resource: *

Effect Resource: protect_AffWebGroup/affwebservices*

Allow Access

Web Agent Action -> Get Post Put

 

Second Rule

Resource: *

Effective Resource: protect_AffWebGroup/affwebservices*

Allow Access

Authorization Event: OnAccessAccept

 

Created Response Attribute tied to Second Rule

WebAgent-OnAccept_Redirect: Here I redirected to the Virtual Host I wanted to handle the Fed Web apps as a Static Attribute

https://federationgateway.example.com/affwebservices/assertionretriever

 

This works fine for redirecting to the static /assertionretriever page on the correct virtual host I want to handle fed apps.

My question is, on the Response attribute, is there a way to grab the $0 portion of the URI from the initial request and append that to the end of the URI

in the response attribute redirect? Almost like on the reverse proxy, this way any request sent to that /affwebservices would then be redirected to the appropriate fed app instead of everything to /assertionretriever.

 

I may be trying to squeeze too much out of this and should stick to the disallow access auth scheme method, but just for creativities sake. Any ideas?

 

Thanks,

Adam

[Legacy User]

Adam

 

Just my way of thinking for sustainability, my preference would be to block at the start (minimize operational overhead & complexity) rather than complicate the solution by allowing a pass through solution (as one being tested) via VHs which are not intended to serve Federation traffic. It is much overhead on processing (interactions between SPS and PS plus processing on SPS) just to pass through to correct VH. It is good to have from User experience perspective, however the overhead / sustainability cost is way too much.

 

 

Circling back to the question.

 

• I would play with VARIABLES Request Context (Server and URI). Please note, there is a defect in R12.52 SP1 CR04 with Variables. Refer to support case 00300147: Variables Request Context. This would be fixed in next release.

 

• There is one another SM Default Header which prints the URI i.e. SM_LOCATION. I would also explore this. But again, I am going to raise a new defect because I am unable to use SM_LOCATION within a configured Response in Policy Server.

 

 

Regards

 

Hubert