Problem: Want to use badges as 2nd factor to authenticate users. Users will recognize face and present badge. In this use case, we assume a user will have a badge that is a combination of 2 or more badges in order to allow enough unique combinations. For valid match for the badge combination to the user, we wish to trigger an unlock action. If badge does not match the face that was present or you wait too long to get matching badges, then a response code can be defined to return a conditional reply. Actions can be triggered on any valid match but not upon a "no match" case.
Syntax for positive match is below.
"factors" : [ "moniker|#0m", "moniker|#1m", "moniker|#2m" ],
Note: This syntax is If using multiple April tags (in this case 3) for each person
April tags only have 512 combinations. (SeeCalculating+Number+of+April+Tags+Combinations). If you only have 512 employees, you are fine with just 1 badge.
The # means the ordinal sequence that a badge appeared. All events come as separate events. #0 means the 1st badge event that arrived. #2 means the 2nd and so on. All three badges (technically the 1st three badge events that appear if someone shows more than 3 badges) must be present in the person record. The system prevents repeat matches so you can't just match same badge from the person record each time. So for example, its ok to have a person record that uses "3', '3', '3' and as long as that person presents 3 April tags, each with #3, they will have success in nFactorAuth. On the other hand, if the person record was '1', '2', '3', and someone presented a badge of '3', '3', '3', this will fail (because you must match unique badge in person record each time). Phew.. ok. That's clear...
Another possible syntax is:
factors : [
"moniker|**",
"moniker|1**",
"moniker|2**",
"moniker|3**"
],
The "*" means any digit. So:
- ** matches any April tag with any 2 digits. (YES: 34, 54, 99. BUT NOT: 2, 3)
- 1** matches any April tag with 1st digit "1" and next any 2 digits. (YES: 134, 154, 199. BUT NOT: 234, 3, 14)
Handling No Matches
So now, how do you handle negated situation? I.e. how do you detect when the person recognized presents a combination of badges with the wrong numbers. Easy! Stan helped me understand the following from docs:
Here is a part of documentation that describes how to define a reply (possibly with sound) on failure to mach a badge:
Response codes for nFactorResolve action:
- Executed action response will supersede
- 0 = resolved last unresolved factor
- >=1 resolved other than last unresolved factor
- -1 = no matching <Site>/<Source>/<name>
- -2 = <mismatched factor - ignored since failOnMismatch = none>
- -3 = <matches but already resolved>
- -4 = <matches but too late to resolve>
- -5 = <mismatched factor - error since failOnMismatched = delayed/immediate>
- -6 = unknown (not defined in nFactorDef) factor_name.
How this works:
- If you get 0 back, that means all badges matched the person record (uniquely)
- If you get value >1, that means so far you have successfully matched all badges but you are not done. For example, if value is 2, that means you have 1 successful match so far.
- If you get one of the negative values, then it means the corresponding error.
So to show the negative message, you need to use the response code per above.
How to Trigger Script on Negated Action?
This is not possible. You can't trigger specific action for the failed nFactor. For example, ActionResponse -5 should trigger action on alarm (e.g. curl http://localhost/alarm.mp3). See below for a possible workaround.
## Workaround
You can use your own 'Reply-Server' if you don't need to use 'ReplyServer'.
- Make your own simple 'Reply-Server' which just need to support the 'POST/stream/{id}'. I think, python is the easiest way to do. When your ‘Reply-Server’ get the following request you can trigger any of alarm.https://cvos.real.com/docs/index.html POST/stream/{id} - Store or update existing stream
- Update your SAFR Action configuration to use your own ‘Reply-Server’. E.g) Listening port is 9292
