IDentiWall for Insurance companies and brokers

The typical case for the insurance business is that every insurance company has multiple insurance brokers and at the same time the insurance broker can work with multiple insurance companies. This presents a number of challenges that need to be met by an adequate solution.

It is quite obvious that token usage will not help security but rather harm it. Imagine a security broker’s office that employs 10 people and represents 10 insurance companies. If each insurance company will issue a token device for each employee of the insurance broker they will have 10x10=100 devices spread all over the office. Since the broker’s employees wish to distinguish between the token and their allocation to the specific employee, they are sure to stick little stickers on each token and specify on them who the token belongs to (user-ID), what is the specific password and/or pin code for that token, which insurance company login does that token facilitate.

Furthermore, sad experience of human frailties assures us that not all those tokens will be securely stored at all times and worse than that, not all the lost or stolen tokens will be reported in a timely manner. And we haven't even begun to discuss the distribution and maintenance nightmare the insurance companies are going to face if they choose the token device path.

IDentiWall for insurance companies and brokers offers a far superior solution. Each employee’s mobile handset will replace all 10 token devices in our example. This guarantees that:

• There are no stickers
• There are no unreported lost or stolen devices
• There is no mess at the broker’s office and no employee’s aggravation.

However, even this elegant solution leaves us with the little problem of number of SMSs that the broker’s employees are going to get every morning when they log onto the various insurance companies’ networks. No employee would like to get 10 SMSs at the same time just because their single sign-on product logged them in to all insurance companies.

The solution is a special developed technology called the ‘Syndication server’. The Syndication server is run outside the insurance company’s network, by Made4Biz, and provides the following functionality:

• Keeps track of any One Time Password (OTP) that was sent to the broker’s employee
• Facilitates a policy engine for the insurance companies

And here is how it works:

• The employee logs onto the first insurance company which can be any of the companies.
• The company’s IDentiWall realizes that it is dealing with a broker employee and diverts the request to the Syndication server which includes an embedded IDentiWall.
• The syndication server sends the employee One Time Password (OTP) via SMS and registers that in its own database with a time stamp.
• Each insurance company can manage its own security policy in the policy engine. For example: company A might decide that the OTP that was sent to the broker’s employee can be also used as an OTP to enter its own network provided that the OTP is not older than 10 minutes. Company B might decide that the OTP can be up to an hour old and company C might decide that they want a new OTP to be sent to the employee in any case.
• Since in a syndication situation the syndication server’s IDentiWall sends the OTP, such diverse policies can coexist in a natural way.
• The syndication server can offer many more services than just authentication service. For example it can act as a central repository of employees who were banned from accessing an insurance company, and use that information according to the specific insurance company’s policy, deciding whether to allow access for such employee to its own network or not.

Since the syndication server is an open platform, its services can be extended to cover additional syndication needs of insurance companies.

See IDentiWall for insurance and other syndicated industries for more details.

More IDentiWall online authentication solutions