IDentiWall Web

Any Web users who wish to implement Multi-Factor authentication and transaction assurance.

• The user starts the login process to the Web server by submitting their User-ID and Password (credentials)
• The IDentiWall session manager sits in front of the web site and gets the request before the Web server.
• The session manager refers the request to the IDentiWall’s Radius server for further processing.
• The Radius server checks if that customer is managed by IDentiWall and if it is, it sends OTP via SMS to the customer’s mobile phone.
• The session manager sends the customer a screen in which the customer is requested to key in the OTP they got.
• Upon receiving the OTP back from the customer, the session manager refers it to the Radius server for comparison.
• If the comparison is successful, the customer’s login request gets referred to the Web server.
• The session manager monitors all the URLs that go through between the customer and web server and when it detects one that was pre-defined as one that gets special treatment, it reads the HTML body and executes the organizational policy.
• An example of an eBanking policy might be: Whenever the customer transfers money, execute transaction verification. This type of transaction verification extracts the sum of money that is being transferred as well as the target account to which the money is supposed to be transferred and send these details (via SMS) to the customer’s phone. The summary is accompanied by ‘OK’ and ‘Not OK’ numeric codes. The customer has to choose the appropriate code and copy it to the form that IDentiWall has sent for this purpose.
• If the customer has submitted the ‘OK’ code, it means that the transaction was not tampered with through browser malware and it should be processed as requested.

• Authentication methods
• Secured Transactions
• SMS sending
• Billing Methods
• HTTP gateway
• Radius server
• Security
• Optional technologies
• SMPP Client & server
• Secured registration
• LDAP client
• SOAP client
• Mobile pre-installed agent
• WAP pushed agent
• SMS routing gateway
• Billing server
• Syndication server

Implementation issues

• Installation
• Set up
• Testing
• Training local staff

• Who serves as the SMS broker?
• Opening an account with the SMS broker
• Who pays for the SMSs, the customer or its users?
• If the users pay (such as in a typical university situation), each user needs to activate their account by purchasing SMS credits in the Billing server.
• Set up the user’s profile of preferences

Licensing issues

• Number of users with pre-paid license fees to be covered by IDentiWall. These users will pay discounted prices for their SMS consumption.
• Does the customer wish to implement Pay-as-You-Go users? For such users the customer has to purchase undiscounted SMS credit.
• Does the customer want that the users to pay for their service? Such users will have to open and/or activate their account by purchasing SMS credits from in the Billing server.

More IDentiWall Authentication Security Products