ActivIdentity ClientCache: Per Session v. Per Process - certificate

Please confirm that I understand these ActivIdentity concepts for a CAC correctly.
Per Session: User runs IE and hits an SSL webpage that requires CAC authentication. He authenticates and ... he's in. If the user opens up another tab (another process), and tries to access that same website, he'll be authenticated already. As a result, he won't need to re-authenticate.
Per Process: User opens first webpage via successful CAC PIN authentication (same as above). Now, when he opens up a new tab to access the SSL website, he'll need to re-authenticate since he's accessing a new process.

I assume you are referring to the ActivClient PIN caching settings?
Per session refers to entire Windows login session. Per process refers to each Windows process that is launched.
So, if PIN caching is set Per Session then, once you have entered the PIN for the card, it will be cached for 15 minutes (default) for any application which requests a card operation in that Windows session. Therefore the user will not be prompted for the PIN again for ANY application until the the PIN cache times out.
In Per Process mode the PIN is only cached for the process which requests it. For example; the users opens IE and logs into a CAC application using a PIN, the PIN is then cached for that particular IEXPLORE.EXE process for 15 minutes (default). If the user then opens Outlook, within the 15 minute window, and tries to sign an email using is card then he will have to enter the PIN as it is not cached for OUTLOOK.EXE. As each IE tab spawns a new process the principal should be the same.
The following is taken from the ActivClient admin guide:
ActivClient PIN cache can be configured to apply either per session (this refers to the
Windows session) or per process (this refers to a Windows process).
Per session mode (the default configuration) allows all the processes in the user’s
Windows session to share the same PIN cache (that is, user authentication is required
once for the entire session whatever the applications used during the session).
In per process mode, the PIN cache is separate for each Windows process (that is,
users need to enter their PIN at least once per process that will use the card).
In both modes, you can further customize the PIN cache behavior for specific
applications by using the Include list, Exclude list and Open card list

Related

How to disable login after multiple failed attempts in Flutter

I have built a flutter app where user is created at backend WEB, in App users can only Login.
What I want to do is if the user attempts multiple failed attempt to login assume for 3 times, I want Login to get disabled for 5 minutes to the user.
help me how to approach it and the best suitable solution.
1.) Create a variable (global variable/ provider) "failed attempts".
2.) On failed attempt increase value =+ 1.
-> When user typed the correct password, delete the current count.
3.) When user failed 3 times -> save CurrentTime in the preference.
4.) Check it before attempting to login again.
-> Current time < (5 Minutes) compared to saved time
-> show popup "Sorry, you have to wait 5 minutes".
As nvoigt pointed out, you can/should store the variables in the backend, to increase security.
I would suggest using storage to store the DateTime of the last failed attempt after N number of failed attempts & checking if current time has passed X days or Y Hours or Z minutes and so on...
Note:
While I am suggesting using the storage for this, it is just out of convinience for you to implement & get going. It is not reliable as the user can change device's date & time settings or can reset/clear storage data.
In case if you are looking for a more secure approach with the same technique use something like firebase DB & Internet time instead of local storage & device time.
What I want to do is if the user attempts multiple failed attempt to login assume for 3 times, I want Login to get disabled for 5 minutes to the user.
This logic must be placed in the backend. When you call the login method on the backend, the backend has to keep track of how many unsuccessful tries there were and then lock the account for a specified time. Make sure you send a specific error code about the account being locked for the period to the frontend, so the frontend can display it and notify the user that trying to login is pointless.
There is no need to block the frontend from trying though. A malicious attacker will work around your protection anyway and a normal user may have reasons to try again (maybe with a different account).
You can use Timer class (link) and set needed delay to it. Block button at incorrect login action and after time runs out set it available again.

IMS Clearwater configuring Application Server

I want to configure application server (in this case Restcomm) to ims clearwater so I added IFC line to /usr/share/clearwater/ellis/web-content/js/app-servers.json. Notice REGISTER SPT method.
"Restcomm" : "<InitialFilterCriteria><Priority>1</Priority><TriggerPoint><ConditionTypeCNF></ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>REGISTER</Method><Extension></Extension></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method><Extension></Extension></SPT></TriggerPoint><ApplicationServer><ServerName>sip:192.168.56.101:5080</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria>"
I want to do scenario
ims registration
but red circled flow is not done.
User created in Ellis Gui is registering fine in IMS but in trace I don't see REGISTER request to application server. What I have to do to achieve that flow except adding IFC line? Based on above flow, should Sprout component send independently REGISTER to AS?
Settings in zoiper for Ellis user. zoiper
[EDIT]
After testing I have some observations, i.a.:
1.When I removed INVITE SPT, and set only REGISTER SPT then flow works as I wanted and described above. So how to set few SPT?
"Restcomm-Register" : "<InitialFilterCriteria><Priority>1</Priority><TriggerPoint><ConditionTypeCNF></ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>REGISTER</Method><Extension></Extension></SPT></TriggerPoint><ApplicationServer><ServerName>sip:192.168.56.101:5080</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria>"
2.Not clear behaviour I noticed, when I created second server (with INVITE only), then provisioned two numbers via ellis gui, first number set to Restcomm-Register (above), second to Restcomm-Invite (below). On the Restcomm AS I have simple sip servlet app which is triggered on Invite and Register requests. I assumed that first number would only trigger simple app only on Register request but NOT! This number can also trigger Invite method... Why is this happennig if Register iFC only is added for first number? I thought that Invite should be send to build-in MMTel AS). On the other hand second number triggers only Invite method as I want.
"Restcomm-Invite" : "<InitialFilterCriteria><Priority>1</Priority><TriggerPoint><ConditionTypeCNF></ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method><Extension></Extension></SPT></TriggerPoint><ApplicationServer><ServerName>sip:192.168.56.101:5080</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria>"
Both servers Restcomm-Register and Restcomm-Invite are the same server (the same IP) but with different SPT.

When to create PFInstallation

I am new to using PFinstallations on Parse, and i am a bit confused as to how they work. I have an app that creates a new installation when a user creates an account, and i set the "User" field of the installation to the users userId so i can send them notifications easily later. I dont understand how the installation works when the user logs out or closes the app. In order to be able to always send the user a notification, must i create new installations periodically when these events (ie. logging out or closing the app) occur?
You shouldn't ever need to create an instance of PFInstallation. The parse framework will handle that for you if you access it using PFInstallation.currentInstallation(). But to save it to the backend, you'll need to call one of the save methods yourself.
By default, logging out will have no impact on the installation since it is a method on the user. You can have you own logic that modifies the installation on logout to, for example, clear the user field or channels.
The parse framework writes the installation to disk on the users device. When the app stops running and then restarts, parse can just read that data from disk and have the proper PFInstallation object again.

How do I get Citrix Xendesktop to treat every client login as a unique Windows session?

I work at a moderately sized company and we currently have Citrix Xendesktop 7 tied in with our AD and domain. We have 25 clients we're having employees test right now via the Web Storefront.
Everyone can log in with their domain credentials fine enough, but the image treats every session as if it is a brand new Windows session whenever they first log in for the day (First-time user prompts for Adobe Acrobat, Word Processor, no initial file associations, etc).
Besides having everyone log directly into the main desktop image to save their profile, how would I go about configuring the applications so they don't treat everyone as a brand new user during each session? (I remember someone saying this could be accomplished through the registry settings but I couldn't pull the thread back up for reference).
I'd suggest Citrix UPM and use group policy for folder redirection. You may just need to configure the settings for your environment. You can then have mandatory or unique profiles set.
XD 7 User Profiles
Folder Redirection

Verify user,password and open menu of rpgs

I have a login module in my application of AS400(rpg400).Here user name and password are verified and only if password matches the user is given access to the Menu screen which further contains rpg programs to navigate to subsequent modules.
What i now want to achieve is when the user is verified, the logged in user name must appear in every screen or rather every rpg screen called.(ie user session must be maintained)Please refrain from guiding on admin properties.This is from a low level point of working.
Below is a PF on users:
USER PF
A R USRREC
A USER 10A
A PWD 10A
A USRTYP 2A
A K USRTYP
Keyed on user type.How can i allow the logged in person's variable accessible to all pgms?
5250 displays aren't like HTML. There's no CSS that can be used as a standard template. You will need to specifically design every display to make it look the way you want it to. For this specific question, that means that you will put a user ID field on every display panel you want to see it on.
If I were designing this, I'd probably pass the user ID as a parameter to each RPG program, but there are many ways to pass information around.
Data area in QTEMP
Database file in QTEMP
LDA
User space in QTEMP
Environment variable (*JOB)
Passing the user ID as a parameter has the advantage that there is never a stale object that needs to be cleaned up. If a person has two user IDs - say she works in Accounting and Accounts Payable - and needs to sign off and back on to this internal security system, subsequent CALLs simply pass the proper parameter.
All of this could be avoided if the system could use the built-in IBM security. Then you could use the user profile that is part of the job name - see the Program Status Data Structure, positions 254-263 to get that within an RPG program. If you could use the IBM user profile, you wouldn't have to pass anything around; each program would be able to retrieve that information on its own; I'd put that into a service program so it's easy to reuse.
Sounds like an ideal use for the local data area or a regular data area created in QTEMP.
RPG: Data Area Data Structure
RPG: Data-Area Operations
If you are using the same user ID that they used to log onto the system, then you can use the USER keyword in your display files.
Do you really need to store user ID and password in a file that is inherently less secure than the way the operating system does it already? This opens a set of issues that you probably don't need to touch.
You can call a CL program or procedure which can use the CHKPWD command to enter their system password. Monitor for an error, and sign them off if there's a problem. Their password is secure (assuming you are using an SSL connection).
If you feel very strongly that you must have a separate password, consider storing a secure one way hash of the password. When they later enter their password, compute the hash on what they enter and compare it to the stored hash.
If you are asking users to enter a password after they are already logged on, then it seems safe to assume you are trying to address some security concern[s], so it seems reasonable to try to help you do so in a secure manner. This is a start.