New post
Question
· Feb 24, 2016

Additional check on cache user authorization

#Authentication #Security #Terminal #Access control #Caché

I need to perform additional checks before Cache user logins (let's say in a terminal for simplicity) and allow access only to those, who passed them. How do I do it?

After reading about delegated authentication in docs I created this ZAUTHENTICATE routine:

ZAUTHENTICATE(ServiceName,Namespace,Username,Password,Credentials,Properties) PUBLIC {
 #include %occErrors
 #include %occStatus
 quit $$$ERROR($$$GeneralError,"No access") 
}

and set Password and Delegated as Allowed Authentication Methods   in %Service_Console (it's a windows install)

Expected result: no one can login via the terminal

Actual results: after entering cache user credentials in a terminal prompt user succsessfully logins but in this user plrofile there is:

Last Reason for Failing to Login: ERROR #5001: No access 

audit reports:

2016-02-24 10:10:00.046 %System %Login LoginFailure 7560   dev Error entering the application Programmer mode
Discussion (14)4
Log in or sign up to continue
Stephen Walasavage · Feb 24, 2016

What version are you running?  I'd say the expected result is a successful login, assuming correct credentials are entered;  we'll try Delegated authentication first, and if that fails, then try Password.  I just tried this with _SYSTEM, and I got one LoginFailure and one successful Login when I view the Audit log.

For the LoginFailure:

Description:  Programmer mode login failure

 

Error message:  No access [ZAUTHENTICATE+1^ZAUTHENTICATE:%SYS]

Service name: %Service_Console

Login routine:  Programmer mode

 

What you described is what I would expect would happen.  If you're looking to restrict access based on code in ^ZAUTHENTICATE, you'll probably need to only have Delegated authentication checked/enabled for the service (this would of course mean the user is of type Delegated User instead of Cache Password User).

http://docs.intersystems.com/cache20152/csp/docbook/DocBook.UI.Page.cls?...

1 0
Steve Pisani · Feb 24, 2016

Hi,

I agree here, with Cache Password Authentication, once authenticated, there isn't any callback of way of extending the authentication with another step (further authentication). 

However - depending on your exact use case, you may use %ZSTART. All processes call into the routine %ZSTART at verious line labels (depending if they are a background job, interactive job, etc).  

see: http://docs.intersystems.com/cache20152/csp/docbook/DocBook.UI.Page.cls?...

 At the stage where you are in %ZSTART, you have already been authenticated - and perhaps, this is where you can craft something to achieve the end result that you are after.  It's worth looking into.

Steve

0 0
Rich Taylor · Feb 24, 2016

Two suggestions:

  1.  try returning a different error message.  One that might indicate an authentication error such as $SYSTEM.Status.Error($$$UserInvalidPassword).  I have not tried it myself, but this may work.  However, as someone else said this is really not the intended purpose of delegated authentication.  
  2. I am not sure about the nature of your additional checks.  However perhaps you can use the Login tag in %Zstart.

These are just suggestions as I have not had the chance to try either yet.

1 0
Timothy Leavitt · Feb 26, 2016

Eduard,

It would help if there was further explanation of your use case. What is the "additional check" in question? Is it a flag on the user at the application level? Is it a call to some other system?

For simplicity, let's suppose your application has a role called TerminalUser that has the %Service_Console:U permission, and that it's the only role an application user might have that grants that permission.

If the "additional check" is based on a flag in your application, your application could simply add/remove the TerminalUser role when that flag changes. See class documentation for Security.* in the %SYS namespace. This might rely on a "privileged routine application" to escalate roles if the user changing this flag wouldn't normally have the necessary privileges to change security settings.

In either case, ZAUTHENTICATE might still work, although it wouldn't be as elegant. It could perform whatever additional checks are needed (against your application or some external system), and possibly add or remove the TerminalUser role based on the results. ZAUTHENTICATE would always return an error, so it falls back to password login. At that point the user could authenticate successfully but might not be allowed to use terminal if the TerminalUser role was removed. (I haven't tried this, but it seems like it could work.)

If you're using OS or Kerberos authentication, ZAUTHORIZE could also be relevant.

1 0
Andreas Dieckow · Mar 10, 2016

The title of the post is not quite correct. You would like to resolve something in the authentication step, not the authorization step. Please take a look at the ZAUTHENTICATE.mac in the SAMPLES namepace that includes a large array of options and code examples (most can be used just by uncommenting them). It also includes an example of performing 2 factor authentication. For this to work you have to validate the user's credientials first and then step into the 2 factor part of the authentication. Let me know if this helps. If not I will get you a more concrete implementaiton of ZAUTHENTICATE.

 

(Also please make sure that your authentication options for the service has the right list of options (in your case problably only delegate authentication)) 

0 0