Symantec Access Management

Hello, We are looking at a scenario where we need to provide IWA authentication for a resource coming from internal users(10.IP address) , and present a form based authentication (served by externally hosted webservers/webagents)when the user comes from out side of network(internet).

IWA authentication servers(IIS Servers) are not available for external users and we dont intend to make it available for external users. Can anyone help me by throwing some references on how to accomplish this?

First is to capture the IP address of the user.

Do we need Agent API for this ?  

Authentication scheme decision based on IP address, I am assuming we need authentication API for it.

Appreciate any insights as to existing function calls/methods available for this, while we are trying to get deeper understanding.

Finally, can out of box 'Fall back authentication' slated to release in R12.7 cover my scenario ? as IWA servers are not available out of box?

Yes, the IWA Fail Over To Forms feature slated to release in R12.7 should cover your scenario.

In the meantime, if you want to implement something now to meet your requirements you do not need to use the agent API or write an authentication scheme, you can do it all in JSP/ASP/JavaScript etc.

From my second reply in the conversation: https://communities.ca.com/ideas/113117040 .....

If the real requirement is to let internal user’s login with IWA, but have external users login with HTML Forms Auth, another possible solution you could implement is:

Use HTML Forms Auth as the method protecting the resources, but use a JSP/ASP/PHP/Servlet etc to display the login form, and include logic that tests for the internal IP Addresses you use (192.168.x.x, 10.x.x.x, etc) and if an internal IP address is detected, redirect to a “helper” realm that is protected with IWA, otherwise display the HTML Form Login Page.

The "helper" realm should be protecting a simple redirect script that will redirect the user to their original TARGET resource once the user is authenticated and authorized. Note that this solution does not provide failover if for some reason an internal user fails IWA authentication. If an internal user fails IWA authentication they will be prompted for BASIC auth credentials by their browser.

Rick

Hello 

I don't think the out of the box Fallback Authentication Scheme (introduced in R12.7) would really help you in this case. The Fall back Authentication scheme only  works with Windows NTLM authentication as first auth scheme and HTML form as your second or fall back auth scheme. So If you are doing IWA using NTML then your Use case can be achieved via R12.7 but If you are doing IWA using Kerberos then your Use case would not be solved by R12.7 PS.

I have a better Idea to achieve this.

Just add a flag in the User directory to identify the users as external.  when authenticating via siteminder check that flag to find out if the user is external or internal and based on that customized Policy Response.  for e.g.

If you already have found that user which is logging to the application is an external user (By fetching the user attribute from the user store) then define a policy which gives you access only when you are internal user. for all external user just throw deny access (SiteMinder Error Code 403).

Now you can write an OnAccessRejectRedirect Rule, which will redirect the external user to a form Login page.

I hope it helps.

Best

SAndeep Khurana

+91-97175-28742

Hi Sandeep,

Contrary to your statement, the use case originally presented is one of the main use cases that the IWA Fail Over To Forms feature available in CA SSO 12.7 is meant to address and does address. Also, IWA using Kerberos is supported by the authentication scheme via the CA Access Gateway. The following quote is from the CA Access Gateway documentation:

The Windows authentication scheme allows CA Single Sign-On to provide access control in deployments with Active Directories running in native mode and Active Directories configured to support NTLM authentication. Windows authentication scheme uses SPNEGO to allow initiators and acceptors to negotiate with either Kerberos or NTLMSSP.

The solution you suggest is not an appropriate solution for this use case because the whole point of IWA is to provide authentication without requiring the user to enter any credentials. Your solution would require a prompt for the user's login ID as a first step before it can be determined what type of authentication scheme to be used. Thus internal users would be required to enter their login ID before IWA would execute to authenticate them.

The link I present above does have an alternate solution to the use case presented above using IP addresses to determine which authentication scheme is presented which does not require any input from the user if they are on the internal network.  

Rick