Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nickel

Legacy authentication and Identity Awareness Difference

Jump to solution

Hi Team, 

 

We are using Legacy Authentication ( Client Auth ) in our environment. We have been recommended by TAC to move to Identity Awareness   as client auth is an old method.

 

But I need to ask  if there is any real advantage of using identity awareness rather than client auth as its still supported in R80.30 ?

The only limitation is that the Client Auth option is available for layers that only have the firewall blade enabled, so this means it cannot be used with the application control blade.

 

What limitations of client auth over identity awareness ?

 

Regards,

Sijeel Malik

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted

Client auth.

1. causes issues with acceleration (connection templates)

2. all authenticated sessions are blown away during a policy push*

3. all sessions are tied to rule number. Insert a rule above the authentication rule and now everyone's session break.

You can work around #2 with a table.def change however you can't for #3.

IA portal doesn't have any of those issues.

View solution in original post

13 Replies
Highlighted
Admin
Admin

Client Auth only allows you to use legacy forms of authentication.
It does not support blades other than firewall or work in policy layers beyond the first layer or with blades other than firewall.
You cannot leverage the additional granularity you get from Access Roles or get pervasive knowledge of acquired identities even in contexts where identity isn’t strictly required.

There may be other limitations present today, or added in the future should you continue to use Client Auth.
Best to migrate away from this legacy feature ASAP.

Highlighted
Nickel

Thanks , 

 

But are there any compatibility issues with using client auth in R80 ? As far as  I know there aren't any

0 Kudos
Highlighted
Admin
Admin

It is incompatible with certain features as we already described in this thread.
There may be additional incompatibilities now or in future versions because, this being a legacy feature, it gets minimal testing in QA.
Identity Awareness has been available for several major versions now.

My question to you: why the resistance to this change?
Is there something Identity Awareness doesn’t do that Client Auth does?

0 Kudos
Highlighted
Nickel

Its more of a political thing  where we need to explain our client  the benefits of migrating to IA  . 

0 Kudos
Highlighted

Hello,

yes there is one difference I can do with client-Auth but not with identity awareness (as I know). With IA it is not possible to limit the duration of a session.

We are using Client-Auth for maintenance-access for partners. With client auth I can limit the session length to, let's say, 4h. With IA I'm not aware of that option.

Is there a option with IA to limit the session length?

Best regards

Sascha

0 Kudos
Highlighted

You can set the timeout for captive portal authentication here, your users would connect to URL https://198.51.100.7/connect in this example, and you would also need to make the captive portal accessible from external interfaces under the Edit button for Access Settings...Accessibility:

CP_timeout.jpg

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted

That could be a solution, but with client auth I could adjust the timeout per rule. That is very flexible. If we know from one partner that he has to do a bigger change, we raise that timeout for that partner to 8h while other partners still have a timeout of 4h. That can be done per rule and so we were able to raise the timeout for one partner only.

Is there a possibility with IA too? At the moment this is the only thing which holds us from changeing to IA for now.

Thank you for your help in advance.

Best regards

Sascha

 

0 Kudos
Highlighted
Employee++
Employee++

Are you familiar with the use of time objects in the access policy?

0 Kudos
Highlighted

I think so, but how can I configure a duration of 4h starting from login with time-objects? If it is possible, I don't know how. Could you please post a picture how that can be configured?

Thank you in advance.

Best regards

Sascha

0 Kudos
Highlighted
Admin
Admin

Time objects gives you a window to access, it doesn’t allow you to adjust the time between reauthentication.
Sounds like an RFE @Royi_Priov 

Tags (1)
0 Kudos
Highlighted

So you're right that you can't do per rule limits however there is another factor i forgot to bring up with IA that may just change how you agree to have client auth rules. Legacy client auth has no way to tell when the access is no longer needed unless someone logs in and hits the sign out button. I think the sun may burn out before that happens. With captive portal you can configure it so that the user needs to keep open a web page and once they close it their access shuts down. This means if someone starts a 8 hour window and finishes in 30 mins the access they had open goes away unlike client auth which would remain open for another 7 hours and 30 mins.

0 Kudos
Highlighted

Client auth.

1. causes issues with acceleration (connection templates)

2. all authenticated sessions are blown away during a policy push*

3. all sessions are tied to rule number. Insert a rule above the authentication rule and now everyone's session break.

You can work around #2 with a table.def change however you can't for #3.

IA portal doesn't have any of those issues.

View solution in original post

Highlighted

You could edit the legacy client auth html pages to link to the new IA portal and tell users to update urls. Could also do a count down with js that then redirects.

0 Kudos