Different IWA Auth Scheme for Internal and EXternal Users

[Pallavi_S]

I have a typical use case here for providing access to the federated applications. there are 2 set of users - Sales and Normal who need to access the same federated applications. The Sales User are into external n/w and Normal users are within company Intranet. The sales user have their details in AD-sales and Normal users use AD-Normal. 

Here is the solution suggested.

 

User tries to access federated application externally >> We check at our SSO side whether the user is Normal or Sales from AD-Normal or Ad-Sales >> No change in flow for Normal User (Internally authenticated through IWA-1, Internal Policy Server Accepts and gets access to Saas app)>> For Sales User External Authentication to be done through IWA-2 (Integrated to Internal Policy Server) and then once successfully authenticated pass the control back to internal SSO and perform user mapping between AD-Sales and AD-Normal and pass the mapped sAMaccount name from AD-Normal and provide access to the Sales user on federated application.

 

I need clarity on:

How will my Internal Policy Server accept the authentication from IWA-2, as IWA-2 will be in other external domain? DO we need to have the cookie provider solution set up here? 

How to do the conditional redirect from SSO to different IWA servers based on user's presence in different ADs ?

[Zen Leow]

Hi Pallavi,

 

From my understanding, you need to have a separate webserver to handle the IWA login of your other AD. there's 2 ways to achieve this.

 

1. Either have a webagent on IIS or use Access Gateway, the server must join the domain which you intend to authenticate against.
2. If it is a remote AD, Either have a webagent on IIS or use Access Gateway, the server must join the local AD that has a forest trust with the remote AD.

 

regards,

Zen

[Pallavi_S]

Thanks Zen, can you further explain how to redirect to IWA-2 server in case IWA-1 is unable to authenticate the user. Can redirection be done based on some attribute in AD-1, e.g distinguishedName. ?

[Zen Leow]

Hi Pallavi,

 

The point is, you can't actually directly redirect to the IWA *.ntc url that you want. You need to create the policies and let policy server do the redirecting for you.

 

What I can think of, the only OOTB way to achieve this solely by configuration is to have 2 realms in your SSO Domain. each having a different Auth scheme applied.

 

Pre-requisite is you must have your IWA agent servers created and added separately into the 2 different AD

You have the 2 groups of users created as separate user directories.

Then you have your auth scheme created, let's call them IWA1 and IWA2

Let's assume the application URL is https://myapp.mycompany.com/

 

In the SSO domain, make sure both usertype 1 and usertype 2 are added as user directories.

 

Your first realm will be for resource "/"

This is protected by IWA1

 

Your second realm will be for resource "/?usertype=2"

This is protected by IWA2

 

In both realms, create "OnAuthAttempt" and "OnAuthReject" rules.

suffice to say, both realms should also have the web agent action rules for GET and POST.

 

In policy, the responses for OnAuthAttempt and OnAuthReject of the "/" realm will have on-reject-redirect to https://myapp.mycompany.com/?usertype=2

 

The responses for OnAuthAttempt and OnAuthReject of the "/?usertype=2" realm will have on-reject-redirect to a common error page that tells the user he/she is not allowed to access the app.

 

In theory, this should work. Good luck

 

regards,

Zen

[Pallavi_S]

Hi Zen,

 

Can you please help me with the steps for configuring my SSO environment if the 2 two iwa servers are in different domains.

IWA1 is in mycompany.org domain and so are the other webagents and Secure proxy servers.

 

IWA2 is the new server that we are setting up and is in the domain mycompany.net

 

What are the important things i need to implment so that my policy server in the same domain (mycompany.org ) accepts the authentication of  the user from IWA2.

 

We have to keep in mind there are several other webagents which are on mycompany.org domain and we dont want to touch them.

 

Thanks,

Pallavi

[Zen Leow]

Hi Pallavi,

 

I'm assuming both AD domains are in different forests so you can't use the global catalog.

 

For IWA to work, the policy server doesn't NEED to be part of any AD domain you can have it join either one is fine. Its the Access Gateways or IIS that is serving the .ntc URL that are important to be in the each of your AD domain.

 

But your policy server MUST have connectivity to both ADs so that you can configure "User Directories". one for each AD. Else your policy server cannot Authenticate/Authorize those users to access resources.

 

I'm also assuming you already have the necessary domain service accounts with the necessary privileges so that policy server can use it to bind when initializing the user directories.

 

Then the rest is creating policies which you can either try my method or the method suggested by PEARSE Kennedy below.

 

You need to try it out then post problems that you face. These configs are SSO domain related. Nothing to do with webagents. Incorporate in SSO Domains that requires both IWA1 and IWA2. Those that don't need IWA2 should just remain as they are.

 

Good luck.

 

regards,

Zen

[Pallavi_S]

Hi Zen,

 

I tried your suggestion as per below:

**************************************************************************************************************************************

 

The point is, you can't actually directly redirect to the IWA *.ntc url that you want. You need to create the policies and let policy server do the redirecting for you.

 

What I can think of, the only OOTB way to achieve this solely by configuration is to have 2 realms in your SSO Domain. each having a different Auth scheme applied.

 

Pre-requisite is you must have your IWA agent servers created and added separately into the 2 different AD

You have the 2 groups of users created as separate user directories.

Then you have your auth scheme created, let's call them IWA1 and IWA2

Let's assume the application URL is https://myapp.mycompany.com/

 

In the SSO domain, make sure both usertype 1 and usertype 2 are added as user directories.

 

Your first realm will be for resource "/"

This is protected by IWA1

 

Your second realm will be for resource "/?usertype=2"

This is protected by IWA2

 

In both realms, create "OnAuthAttempt" and "OnAuthReject" rules.

suffice to say, both realms should also have the web agent action rules for GET and POST.

 

In policy, the responses for OnAuthAttempt and OnAuthReject of the "/" realm will have on-reject-redirect to https://myapp.mycompany.com/?usertype=2

 

The responses for OnAuthAttempt and OnAuthReject of the "/?usertype=2" realm will have on-reject-redirect to a common error page that tells the user he/she is not allowed to access the app.

 

*************************************************************************************************************************************

But the issue is that OnAuthReject Redirect Rules are not getting triggered even when the user is putting in the incorrect credentials(username or password).

We are facing below issues:

1. We are getting constantly prompted by IWA-1 on the server to provide the credentials. Is there any way we can stop getting prompt ? I checked in the IE browser option and have option for IWA authentication already checked. 

2. In case we provide wrong userid and password fallback to IWA-2 doesn't happen. It keeps showing prompt coming from iwa-1.

 

Thanks,

Pallavi.

[Zen Leow]

 

Was this selected in the browser too?

[Pallavi_S]

Checking on this option with the user.

Can u suggest if this option is checked the fall back will happen from IWA-1 to IWA-2 automtically? 

[Zen Leow]

Sorry to have gotten your hopes up on this. looks like my suggestion will not work in pure IWA configurations. Because the authentication isn't done by the Agent so there will not be any authentication events.

 

But Pearse's recommendation is sound. I didn't fully test with 2 ADs, but using authentication chaining, you can at least let it fallback to a web resource of your choice, then in the "form", you have code to redirect to a resource that is protected by your IWA2. I tested redirecting and it should work. No form need to appear

 

regards,

Zen

[Pallavi_S]

Zen but Pearse solution is based on a pure IWA auth on CA Access Gateway. In my case i have a different VM on windows acting as IWA server, my CA access gateway is on another VM.

[Zen Leow]

Hi Pallavi,

 

I'm still unclear what your setup is like. To use Authentication chaining, you need CA Access Gateway instead of IIS. Here's what I think you need for this to work. To simplify things, I am assuming you have a common landing page for your users to access before traversing to other applications. E.g. https://www.mycompany.com/dashboard/ 

 

I am also assuming you are already well versed in agent creation, Directory creation, SSO domain creation, selection of correct agent in realm settings, rules, policies so I won't go into detail on those in this list of steps.

 

1. CA Access Gateway in Windows joined to AD1 domain (let's call this iwa1.company.com).
2. CA Access Gateway in Windows joined to AD2 domain (let's call this iwa2.company.com).
3. Create a custom jsp or aspx page in where ever you like, if you are using access gateway, there's already a tomcat server built in. I like to use the Tomcat/webapps/affwebservices/redirectjsp/ folder to place this sort of resources. Let's call this https://somewhere.mycompany.com/affwebservices/redirectjsp/gotoiwa2.jsp . This jsp content have nothing but a line to redirect to https://www.mycompany.com/dashboard/?usertype=2
   
   <%
   response.sendRedirect("https://www.company.com/dashboard/?usertype=2");
   return;
   %>
    
4. Create a login form as the final ultimate fallback. you can use the out of box login.fcc but I find it aesthetically unpleasing to the eyes so best to make a nice looking login form that posts to login.fcc instead. We'll call this https://www.company.com/auth/login.jsp 
5. Create IWA1 auth scheme pointing to IWA1 (e.g. https://iwa1.mycompany.com/siteminderagent/ntlm/creds.ntc)
6. Create IWA2 auth scheme pointing to IWA2 (e.g. https://iwa2.mycompany.com/siteminderagent/ntlm/creds.ntc)
7. Create Form auth scheme (gotoiwa2) pointing to https://somewhere.mycompany.com/affwebservices/redirectjsp/gotoiwa2.jsp 
8. Create Form auth scheme (finalFormLogin) pointing to https://www.company.com/auth/login.jsp 
9. Create Authentication Chain Auth scheme (IWA1Chain) to chain IWA1 auth scheme and gotoiwa2 form auth scheme.
10. Create Authentication Chain Auth scheme (IWA2Chain) to chain IWA2 auth scheme and finalFormLogin form auth scheme.
11. You can have other Access Gateways/Web agents in Linux or whatever it doesn't matter. Authentication is base on auth scheme and will redirect back and forth accordingly.
12. Create a realm for "/dashboard/" and assign "IWA1Chain" as authentication scheme
13. Create a realm for "/dashboard/?usertype=2" and assign "IWA2Chain" as authentication scheme
14. Create a realm for "/affwebservices/redirectjsp/gotoiwa2.jsp" and set it as unprotected
15. Create a realm for "/auth/login.jsp" and set it as unprotected.

 

IF this works, here's what will happen.

 

Scenario 1: User using an account that is joined to AD1

1. User login to computer as AD1 user
2. open Internet explorer and access https://www.company.com/dashboard/
3. SSO redirects user to https://iwa1.mycompany.com/siteminderagent/ntlm/creds.ntc
4. Authentication successful and user is brought back to https://www.company.com/dashboard/ with a valid SSO session.

 

Scenario 2: User using an account that is joined to AD2

1. User login to computer as AD2 user
2. open Internet explorer and access https://www.company.com/dashboard/
3. SSO redirects user to https://iwa1.mycompany.com/siteminderagent/ntlm/creds.ntc
4. Authentication failed and redirect (fallback) to https://somewhere.mycompany.com/affwebservices/redirectjsp/gotoiwa2.jsp 
5. gotoiwa2.jsp does nothing but redirects to https://www.company.com/dashboard/?usertype=2 
6. SSO redirects user to  https://iwa2.mycompany.com/siteminderagent/ntlm/creds.ntc
7. Authentication successful and user is brought back to https://www.company.com/dashboard/?usertype=2 with a valid SSO session.

 

Scenario 3: User using a browser that is not IWA enabled (maybe Chrome/Firefox or IE without the correct setting) or using a non domain windows login.

1. User login to computer as anyone (can be AD1 or AD2 or local user)
2. open any browser and access https://www.company.com/dashboard/
3. SSO redirects user to https://iwa1.mycompany.com/siteminderagent/ntlm/creds.ntc
4. Authentication failed and redirect (fallback) to https://somewhere.mycompany.com/affwebservices/redirectjsp/gotoiwa2.jsp 
5. gotoiwa2.jsp does nothing but redirects to https://www.company.com/dashboard/?usertype=2 
6. SSO redirects user to  https://iwa2.mycompany.com/siteminderagent/ntlm/creds.ntc
7. Authentication failed and redirect (fallback) to https://www.company.com/auth/login.jsp .
8. User enter either AD1 or AD2 credentials into form.
9. Authentication successful and user is brought back to https://www.company.com/dashboard/?usertype=2 with a valid SSO session.

 

The above is all I can add on this subject. I did not fully test this flow but all the bits and pieces are workable blocks so piecing them together should work fine. You'll need to work out how the above can be applied in your environment.

 

I wish you luck.

 

regards,

Zen

[Pallavi_S]

Thanks Zen for such an elaborate explanation. really appreciate your efforts to help me fix the issue.

 

Just one concern I have this use-case is for the federation e.g.. so if the redirect the user from the html form gotoiwa2.jsp to 

https://www.company.com/dashboard/?usertype=2,

will be query string in the URL e.g. Target, SMPORTAL, SAMLTRANSACTIONID will get preserved i think i will loose it all the SSO wont know how the request originated and which federation partnership is being called.

[Zen Leow]

Hi Pallavi,

 

This method works best if there is a common landing page that is not federated and hosted internally. Then the common landing page have the links to the federated applications. by the time the common landing page is loaded, an SMSESSION would have been created and clicking on the federated links will just work accordingly.

 

if you can't have that, then you'll probably need to create a set of the stated authentication schemes and realms for each of the federated apps. that means having multiple gotoiwa2.jsp and proxy pages that redirects to the federated apps after login is done. I would limit SAML to IdP initiated flows in this case.

 

Good luck.

 

regards,

Zen

[Pallavi_S]

Zen, with the common landing page are you referring to the https://mycompany.com/siteminder/affwebservices/redirect.jsp page

which is protected by SSO and having the IWA based authentication scheme to authenticate the user?

[Zen Leow]

Hi Pallavi,

 

Not that. I'm referring to something like an enterprise portal page that all staff must first login to and it has links to all the applications available to the logged in user. So you apply the authentication chaining on this portal page. When the user login successfully, they will already have an SSO session. After that clicking on the federated app links will just have to let affwebservices do its thing without you having to worry about authentication since user is already authenticated.

 

regards,

Zen

[kenpe02]

As mentioned in another post, if both AD domains are in the same forest, you could use a single auth scheme and validate against the AD global catalog

 

If both domains are completely separate, you might be able to do something with authentication chaining using the Access Gateway. I haven't tried this, but basic idea is user tries to do IWA against Access Gateway in domain A. If that fails, user falls back to form-based auth scheme. But make the form-based auth scheme point to a JSP on an Access Gateway installed in domain B. This then redirects to a local IWA to authenticate the user against domain B. You then need to redirect the user back to the original resource.

That's it at a pretty high level, You'd need to work out all the redirect and domain/realm/policy details

[Zen Leow]

That's a cool way to chain IWA auth schemes.

 

How I wish Authentication Chaining can expand support to fallback to another auth scheme other than form-based only.

[Pallavi_S]

Hi Zen,

 

Please answer my above query related to solution for having iwa servers in different domains

 

Thanks.

[Pallavi_S]

Pearse, I'm having a separate server proving IWA functionality on Windows Platform. The SPS/CA ACcess Gateway server is on linux environment

[Zen Leow]

you are using Access Gateway to provide IWA but you are running it from Linux? The only config that I know works for IWA is the Access Gateway needs to be a windows box added to the Active Directory domain.

[Pallavi_S]

No no. I believe ive been mis-interpreted. My IWA server is a separate VM running on windows. This VM is dedicated for IWA authentication.

Ive another VM for CA Access Gateway running on Linux.

[Zen Leow]

Use Pearse's suggestion. It is a lot cleaner and should work. mine is a dud.