This application is a continuation application of, and claims priority to, U.S. patent application Ser. No. 11/593,992, filed Nov. 7, 2006, the disclosure of which is incorporated herein by reference in its entirety.
The present invention relates generally to computer-based methods and apparatuses, including computer program products, for triggering authentication rules for service provisioning.
Hackers are becoming increasingly adept at identity theft in electronic commerce. Viruses, Trojan horses, worms, and spyware are used by hackers to install malware programs on consumers' systems to look for consumers visiting electronic commerce sites and entering their credentials. Malware programs can collect consumers' authentication data and other sensitive data by monitoring the keystrokes typed in by the user and sending them back to the hacker. The hacker is then able to log in to the consumers' accounts to damage or disrupt it (e.g., steal from it). Explicit sharing by the consumer, capture by man-in-the-middle devices, and guessing are other means used to compromise sensitive data. The compromises of authentication credentials expose service providers and their customers to the potential for financial loss and identify theft.
With respect to providing secure electronic commerce, service providers implement rigid authentication processes for their consumers to access their services. Typically, the authentication process involves a customer identifier and a password known only to the consumer. For more sensitive electronic commerce areas, a multi-factor authentication process is used involving, for example, a hard-token in addition to the traditional usermame and password.
One approach to providing customizable authentication for service provisioning is to enable a user to customize an authentication system. In one aspect, there is a computerized method. The method includes enabling a first user to customize an authentication system associated with a service type. Customizing the authentication system includes defining one or more authentication rules for determining access for a second user to a service for the service type.
In other examples, any of the aspects above can include one or more of the following features. The first user can include a consumer organization or an organization subgroup of the consumer organization. The first and second user can include an individual consumer. The second user can include one or more individual consumers of the first user. The method can further include enabling the second user to customize the authentication system associated with the service type. The one or more authentication rules comprise: a mandatory rule, an optional rule, or any combination thereof.
In addition, the method can further include receiving, from the second user, a request for the service at an enforcement point. The method can further include generating a rules credential including the one or more authentication rules. Generating the rules credential can be based on: a characteristic of the second user, a characteristic of the request, a characteristic of the enforcement point, or any combination thereof. The characteristic of the second user can include an identification credential of the second user, an identification credential of a group of users including the second user, or any combination thereof. The characteristic of the request can include: an access-channel characteristic, an access-point characteristic, a device characteristic, or any combination thereof. The characteristic of the enforcement point can include: a time characteristic, a day characteristic, a policy characteristic, a service type characteristic, a function type characteristic, or any combination thereof. The method can further include receiving, from the second user, a second request for a second service at a second enforcement point different from the first enforcement point. The second request can include the rules credential. The method can further include executing, at the second enforcement point, at least one of the one or more authentication rules included in the rules credential.
In various embodiments, the method can further include receiving, from the second user, a request for the service at an enforcement point. The method can further include determining if the one or more authentication rules apply to the second user at the enforcement point. The method can further include executing an authentication action specified by the one or more authentication rules when the one or more authentication rules apply.
In some embodiments, determining if the one or more authentication rules applies can include determining if one or more triggers specified by the one or more authentication rules are triggered. The one or more triggers can include: a user trigger, a request trigger, an enforcement point trigger, a policy trigger, or any combination thereof. The request trigger can include: an access-channel trigger, an access-point trigger, a device trigger, or any combination thereof. The method can further include triggering the access-channel trigger when the second user attempts to access the service using: a web message, a universal resource locator (URL) message, electronic mail, text messaging, instant messaging, a session initiation protocol (SIP) message, a short message service (SMS) message, a multimedia messaging service (MMS) message, an enhanced messaging service (EMS) message, an IP multimedia system (IMS) message, a live voice call, an automated voice call, an interactive voice response (IVR) call, or any combination thereof. The method can further include triggering the access-point trigger when the second user attempts to access the service from a specified network access-point.
In various embodiments, the enforcement point trigger can include: a time trigger, a day trigger, a service type trigger, a function trigger, an expiration-of-time trigger, or any combination thereof. The method can further include triggering the service type trigger when the service type matches a specified service type. The specified service type can include: a retail services type, an employment services type, an insurance services type, or any combination thereof. The method can further include triggering the function trigger when the service matches a specified service. The specified service can include: a financial service, an accounting service, a personnel service, an administrative service, a trade service, or any combination thereof. The method can further include triggering the time or date triggers when the second user attempts to access the service during: a specified time range, a specified day of the week, a specified set of dates, or any combination thereof.
In various embodiments, the policy trigger can include a fraud trigger. Executing the authentication action can include blocking the second user from accessing the service, and directing the second user to a site different from the enforcement point. Executing the authentication action can also include providing access to the service to the second user, and executing a supplemental action when the second user accesses the service. The supplemental action can include a monitoring action.
In addition, the method can further include receiving, from the second user, a request for the service at an enforcement point. The method can further include determining if the second user satisfies the one or more authentication rules, and providing access to the service to the second user if the second user satisfies the one or more authentication rules. The method can further include executing a first authentication action if the second user does not satisfy the one or more authentication rules. The method can further include determining if the enforcement point includes an override, and providing access to the service to the second user if the enforcement point includes the override.
In some embodiments, the first authentication action can be specified by the one or more authentication rules. The first authentication action can be specified by the enforcement point. Determining if the second user satisfies the one or more authentication rules can include determining a satisfaction state of the one or more authentication rules. Executing the first authentication action can include redirecting the second user to an authentication site separate from the enforcement point. The method can further include modifying a satisfaction state of the one or more authentication rules based on a result of the first authentication action.
In various embodiments, the first authentication action can include: a hard token action, a soft token action, a personal identification number (PIN) action, a password (PW) action, a knowledge action, a biometric action, a modify-user information action, or any combination thereof. Determining if the second user satisfies the one or more authentication rules can include processing the one or more authentication rules in an order specified by one or more priority characteristics of the one or more authentication rules. The one or more priority characteristics can include: a priority code, a priority class, a priority type, a priority context, or any combination thereof.
Any of the above implementations can realize one or more of the following advantages. Customized authentication for service provisioning allows flexibility in the specification, evaluation, and satisfication of authentication and navigation requirements. In addition, the above implementations can provide for the ability to incrementally introduce new forms of authentication into an already operable system and the ability to provide scalable, high-performance authentication implementations. In addition, customized authentication requirements applied to an individual or group of users allows a service provider flexibility when describing authentication requirements for various groups or classes of users. Granularity in the application to the users allows the service provider to provide different authentication requirements to different groups as necessary. In addition, enabling more than one entity to customize authentication requirements for the same user or group of users allows different entities the ability to construct rules relevant to their needs independently from the needs of other entities. In addition, enabling an entity to impose customized authentication requirements on a group of users specified by common characteristics allows imposing entities to define authentication requirements that vary across their universe of users and across the resources that they offer to users.
In addition, enabling an entity to impose customized authentication actions allows the entity to build authentication requirements using any of the supported mechanisms and to add new mechanisms without interfering with those already available in a system. In addition, enabling an entity to impose mandatory or optional authentication requirements on the entity's users allows the entity to create minimum standards for authentication and allows them the ability to offer a spectrum of additional services that provide the user with a spectrum of cost benefit choices. In addition, enabling an entity to structure authentication requirements to segment services under different authentication requirements allows the flexibility and ability to control user navigation based on characteristics of the user and characteristics of the services. In addition, authentication processing conducted locally at fulfillment processing locations allows service providers to scale the service delivery system to accommodate changing or growing loads. In addition, authentication grouping, imposed independently or jointly by different entities, improves the user experience by sharing the satisfaction of authentication requirements across aggregates of related requirements. In addition, prioritizing authentication rules based on authentication priority ensures that users perform actions in a desired sequence relative to other actions.
In addition, enabling different fulfillment types of authentication rules allows imposing entities to either attach actions to the normal flow of user navigation or enforce navigational restrictions. The variety of fulfillment options offered allows imposing entities flexibility in specifying the time extent of authentication requirements and the ability to impose, quickly and easily, local actions or restrictions on classes of users. This also can allow imposing entities to react and respond to changing conditions simply by introducing new or changed authentication requirements, while not changing the service delivery machinery. In addition, authentication triggering allows imposing entities extensive options for specifying when and where users must respond to authentication requirements. The various criteria can allow imposing entities to restrict authentication requirements to only those conditions to which they meaningfully apply. In addition, authentication requirements based on a source address of the user allows an imposing entity or service provider the ability to reduce exposure to problems by monitoring or restricting admittance based on information mined from previous experience across the available resources or from outside knowledge gained from commercial protection or law enforcement agencies.
Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating the principles of the invention by way of example only.
The foregoing and other objects, features, and advantages of the present invention, as well as the invention itself, will be more fully understood from the following description of various embodiments, when read together with the accompanying drawings.
FIG. 1 is a block diagram showing an exemplary network with devices relating to customizable authentication for service provisioning.
FIG. 2 illustrates a flowchart depicting authentication customization and service provisioning.
FIG. 3 illustrates exemplary relationships between rule-creating sponsors and consumers.
FIG. 4 illustrates an exemplary authentication rule.
FIGS. 5-25 illustrate flow diagrams depicting use case examples for authenticated service provisioning.
FIG. 1 is a block diagram showing an exemplary network 100 with devices relating to customizable authentication for service provisioning. The network 100 includes a transmission medium 110 , one or more user devices 120 a , 120 b , and/or 120 c , generally 120 , one or more servers 130 a , 130 b , and/or 130 c , generally 130 , at least one authentication server 140 , a rules server 141 , and/or one or more device managers 145 a , 145 b , and/or 145 c , generally 145 . The transmission medium 110 is responsible for the transfer of information between one or more of the user devices 120 , one or more of the servers 130 , the authentication server 140 , the rules server 141 , and/or one or more of the device managers 145 .
Information transfer over the transmission medium 110 can be based on one or more communication protocols and/or communication modes. Communication protocols can include, for example, Internet Protocol (IP), Voice over IP (VOIP), Peer-to-Peer (P2P), Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), Really Simple Syndication (RSS), podcasting, Signaling System #7 (SS7), Global System for Mobile Communications (GSM), Push-to-Talk (PTT), PTT over Cellular (POC), and/or other communication protocols. Communication modes can range from textual modality (e.g., electronic mail and/or instant messaging) to graphical modality (e.g., still and/or moving pictures) to audio modality (e.g., voice calls), or any combination thereof.
The transmission medium 110 can include one or more packet-based networks and/or one or more circuit-based networks in any configuration. Packet-based networks can include, for example, the Internet, a carrier Internet Protocol (IP) network (LAN, WAN, or the like), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., a Radio Access Network (RAN)), and/or other packet-based networks. Circuit-based networks can include, for example, the Public Switched Telephone Network (PSTN), a legacy private branch exchange (PBX), a wireless network (e.g., a RAN), and/or other circuit-based networks.
The transmission medium 110 can be coupled to the user devices 120 by connections 115 . The user devices 120 can be computers, telephones, IP phones, mobile devices (e.g., cellular phones, personal digital assistant (PDA) devices, laptop computers, and/or the like), and/or other communication devices. Connections 115 can include electrical wires, optical fibers, and/or wireless transmissions. User devices 120 can be identified by a unique and/or shared identifier. A unique user device identifier can be, for example, a telephone number, an IP address, and/or the like. A shared user device identifier can be, for example, a network address, an area code, a country code, and/or the like.
The transmission medium 110 can also be coupled to one or more servers 130 . The servers 130 can include, for example, web servers, application servers, media servers, gateways, softswitches, and/or the like. A server 130 can be responsible for providing one or more types of services to a consumer using one or more of the user devices 120 . Types of services can include, for example, financial services, accounting services, transaction services, communication services, database services, administrative services, and/or other electronic services. Financial services can include banking services, investing services (e.g., stock trading), accounting services, electronic funds transfer services, insurances services, employee information services (e.g., employee benefits), institutional services, administrative services, and/or other electronic services. Transaction services can include shopping, selling goods, trading goods, and/or the like. Communication services can include voice communication (e.g., Voice over IP (VOIP)), data communication, multimedia communication (e.g., video conferencing), networking (e.g., social networking, blogging, etc.), and/or the like. Database services can include library services, research services, news services, and/or the like. In one configuration, for example, server 130 a can be a website for a bank providing financial services associated with checking and savings accounts of individual consumers. In another configuration, server 130 b can be a website for a car insurance unit of an insurance company providing insurance services associated with an insurance policy for a group of small businesses. In yet another configuration, server 130 c can be an automated phone server for an employer providing employee benefit services associated with the employees of the employer.
Each server 130 a , 130 b , and 130 c can include, respectively, an authentication monitor 160 a , 160 b , and 160 c , generally 160 . An authentication monitor 160 can determine access to and navigation of one or more services provided by a server 130 , by the enforcement and execution of authentication rules, discussed below. In the system 100 , the authentication monitors 160 are illustrated to be included in the servers 130 , but other configurations can also be used. For example, the authentication monitors 160 can be directly or indirectly connected to the respective servers 130 .
The determination of access to and navigation of services on one or more servers 130 can be defined and controlled by one or more authentication rules. The authentication server 140 and/or the rules server 141 can be responsible for determining which authentication rules are associated with a user and acquiring the authentication rules when a user logs in and/or requests a service as they navigate the network 100 . The authentication server 140 can also be responsible for executing one or more authentication rules at the time the user logs in to request a service from a server 130 , or at any other time after the user is logged in as they navigate one or more services provided by one or more servers 130 . One or more authentication rules can be stored on and retrieved from a rules server 141 and/or one or more device managers 145 . The rules server 141 can be, for example, a repository database. In another configuration, the rules server 141 can be coupled to a repository rules database. A device manager 145 can be a server, a repository database, and/or the like.
In the system 100 , the rules server 141 and the device managers 145 are illustrated to be directly connected to the authentication server 140 , but other configurations can also be used. For example, the rules server 141 and/or one or more device managers 145 can be included in the authentication server 140 , or can be directly or indirectly accessible by the authentication server 140 over the transmission medium 110 . In addition, the system 100 also illustrates the authentication server 140 to be directly connected to the transmission medium 110 , but other configurations can also be used. For example, the authentication server 140 can be indirectly connected to the transmission medium 110 and/or can be directly connected to or included in a server 130 .
FIG. 2 illustrates a flowchart 200 depicting authentication customization and service provisioning. The elements of the flowchart 200 are described using the exemplary network 100 of FIG. 1. Customizable authentication includes defining one or more authentication rules ( 210 ). Service provisioning includes receiving, from a user, a request for a service ( 220 ), generating a rules credential that includes one or more authentication rules ( 230 ), determining whether one or more authentication rules apply ( 240 ), processing one or more applicable authentication rules if they apply ( 250 ), determining if more authentication rules are applicable ( 260 ), and/or provisioning the requested service ( 260 ).
A sponsoring user can define one or more authentication rules ( 210 ) to determine a consuming user's access to a service. A sponsoring user can include, for example, a client organization or company of a service provider, a unit or group of the organization or company (e.g., marketing group, research and development group, regional group, etc.), and/or one or more individual clients of a service provider. A sponsoring user can also include a service provider. A consuming user can include, for example, one or more individual consumers of the sponsoring user. The consuming user can also be defined according to specified user characteristics. User characteristics can include belonging to a certain organization or company (e.g., users associated with a company), belonging to a group or sub-group of an organization or company (e.g., full-time, part-time, or contracting employees), and/or belonging to other groups of individuals. For example, the sponsoring user can be an employer that uses a service provider to manage employee benefit services. In this example, a consuming user can be the group of all full-time employees. In another example, the sponsoring and consuming user can be the same individual. For example, the sponsoring and consuming user can be an individual consumer of an online trading service provider. In yet another embodiment, the consuming user can be enabled to further add, remove, and/or edit one or more of the authentication rules defined by the sponsoring user. In another embodiment, the sponsor can make one or more authentication rules to be either mandatory or optional for a consuming user.
FIG. 3 illustrates exemplary relationships between rule-creating sponsors and consumers. Sponsoring users can include an organization 310 and/or one or more individual users 320 . The organization 310 includes sponsoring business units 330 and 340 , which, in turn, can include one or more individual users. The sponsoring business unit 340 includes sub-organization and/or client groups 341 and 342 . The sponsoring entities can generate or edit authentication rules using a rules manager 350 . For example, the sponsoring organization 310 can customize ( 361 ) an authentication rule for one or more users in the enterprise 310 (i.e., any combination of users A i , B i , and/or C i ). The sponsoring business unit 330 can customize ( 362 ) an authentication rule for one or more users in the business unit 330 (i.e., any combination of users A i ). The sponsoring business unit 340 can customize ( 363 ) an authentication rule for one or more users in the business unit 340 (i.e., any combination of users B i and/or C i ). The sponsoring sub-organization or client 341 can customize ( 364 ) an authentication rule for one or more users in the sub-organization or client 341 (i.e., any combination of users B i ). The user C N in the sub-organization or client 342 can customize ( 365 ) an authentication rule to be applicable to user C N . The individual user D N can also customize ( 366 ) an authentication rule to be applicable to user D N . The rules manager 350 can generate ( 367 ) specific authentication rule instances for specific users (e.g., users associated with a unique user identifier), or can generate ( 367 ) authentication rule templates for an authentication rule associated with one or more other user characteristics. The generated authentication rules can be transferred to an active rules database 355 .
Generally, authentication rules govern the behavior of components of the network 100 with respect to a user's access and navigation of the network 100 . Specifically, an authentication rule can: define who the rule is to be associated with (e.g., a particular consumer), when it is to apply (e.g., when a consumer attempts to access a specific server 130 and/or a specific service on a server 130 ), what action needs to be performed (e.g., enter a hard token value), and/or how the action can be fulfilled (e.g., redirect the user to a specified universal resource locator (URL) message for entering a hard token value).
FIG. 4 illustrates an exemplary authentication rule 400 . The authentication rule 400 can include authentication rule data 410 , one or more authentication rule trigger sets 420 , 430 , and 440 , and/or one or more authentication rule instructions 421 , 431 , and 441 , respectively associated with an authentication rule trigger. In a supplemental or alternative embodiment, one or more authentication instructions can be associated with an authentication trigger. In a further supplemental or alternative embodiment, one or more authentication states 422 , 432 , and 442 , can be associated with or included in, respectively, one or more authentication rule trigger sets 420 , 430 , and 440 .
Authentication rule data 410 can define what entity (i.e., consuming user) the authentication rule 400 is to be associated with when that entity requests a service and/or logs on to a system. The authentication rule data 410 can also state one or more authentication actions that need to be executed if the authentication rule 400 applies. Authentication actions can include, generally, any challenge that requires a response from the user. Specifically, authentication actions can include: a hard token action, a soft token action, a personal identification number (PIN) action, a password (PW) action, a knowledge action, a biometric action, a modify-user information action, and/or other actions. A hard token action can be implemented, for example, using a smart card and/or a token device. A soft token action can be implemented, for example, using an electronic certificate, an electronic credential, an electronic cookie, and/or the like. Knowledge actions can include, for example, question and answer actions. Modify-user information actions can include requesting the user to edit their user profile. Authentication actions can also include actions that do not require a response from a user. For example, a non-responsive actions can include blocking access to a service (e.g., a Navigation Restriction-type rule), monitor a user (e.g., an Information-type rule), and/or re-directing a user to a different resource. Navigation Restriction-type authentication rules can specify an action that limits a user's navigation across the network 100 by redirecting, for example, the user to a different site than the one requested. Information-type authentication rules can specify that an action is to be executed locally at an enforcement point.
Authentication rule data 410 can also include selection criteria based on one or more specified characteristics. Selection criteria can be used to select which authentication rules should be retrieved to be associated with a specific user, which can take place at the beginning of a session or during a session as the user navigates one or more services of the network 100 . Selection criteria can include characteristics of a user, characteristics of a request for a service, characteristics of an enforcement point, and/or other characteristics. Characteristics of a user can include a user identification, an organization or sub-organization identification, and/or other identifiers.
Characteristics of a request can include an access-channel characteristic, an access-point characteristic, a user device characteristic, and/or the like. Access-channel characteristics can include, for example, accessing a service using one or more of: a web message, a universal resource locator (URL) message, electronic mail, text messaging, instant messaging, a session initiation protocol (SIP) message, a short message service (SMS) message, a multimedia messaging service (MMS) message, an enhanced messaging service (EMS) message, an IP multimedia system (IMS) message, a live voice call, an automated voice call, an interactive voice response (IVR) call, and/or the like.
Access-point characteristics can include, for example, requests originating from a specified address (e.g., IP address, telephone number, etc.), a specified network address (e.g., IP network addresses, area codes, country codes, etc.), and/or the like. Device characteristics can include, for example, software characteristics (e.g., browser agent), hardware characteristics (e.g., brand, model, version, etc.), and/or the like. Characteristics of an enforcement point can include, for example, time(s) of a day, day(s) of a week, a policy characteristic (e.g., a sponsor or owner of the service/resource), a service type characteristic (e.g., banking), a function type characteristic (e.g., setting up a new account), and/or the like.
Authentication rule trigger sets 420 , 430 , and/or 440 , can define when the authentication rule 400 applies at one or more enforcement points. The enforcement points (e.g., an authentication server 140 or an authentication monitor 160 ) can include enforcement contexts that if they match up with one or more triggers in the sets 420 , 430 , and/or 440 , then the authentication rule 400 is triggered and executed. The authentication rule trigger sets can be inclusive, exclusive, or any combination thereof. For example, if the authentication rule trigger set 420 is inclusive, then the authentication rule 400 is triggered when some enforcement point context matches any one of the triggers in the set 420 (i.e., boolean ‘OR’ logic). If the authentication rule trigger set 430 is exclusive, then the authentication rule 400 is triggered when no context or user authentication value matches any one of the triggers in the set 430 (i.e., boolean “AND NOT” logic). Generally, any boolean expression can be used with one or more triggers in one or more trigger sets to activate an authentication rule. If no triggers are included in an authentication trigger set 420 , 430 , and/or 440 , then by default, the authentication rule 400 can be triggered everywhere.
Authentication rule trigger sets 420 , 430 , and/or 440 can include, for example, one or more of: a user trigger, a request trigger, an enforcement point trigger, a policy trigger, and/or the like. A user trigger can include a user identification, an organization or sub-organization identification, and/or other identifiers. A request trigger can include an access-channel trigger, and access-point trigger, a user device trigger, and/or the like. Access-channel triggers can include access-channel characteristics, as described above. Access-point triggers can include access-point characteristics, also described above. Device triggers can include device characteristics, also described above. Enforcement point triggers can include, for example, expiration time(s) trigger, time(s) of a day trigger, day(s) of a week trigger, a service type trigger, a function type trigger, and/or the like. A policy trigger can include a sponsor trigger, a resource owner trigger, and/or the like. Triggers can also specify execution of the authentication rule 400 during login process (i.e., front door processing) and/or during subsequent user navigation of the network 100 (i.e., deferred processing).
Authentication rule instructions 421 , 431 , and/or 441 , can define how the authentication rule 400 can be fulfilled. Authentication rule instructions 421 , 431 , and/or 441 , can include one or more instructions to be performed locally and/or remotely, and/or can include a link (e.g., a URL) to a different enforcement point in the network 100 . Enforcement points can include, for example, an authentication server 140 , a device manager 145 , and/or an authentication monitor 160 . If the authentication rule 400 does not have an authentication action specified, then an enforcement point can use a default action. For example, an authentication monitor 160 can, by default, direct a user to the authentication server 140 in cases where an authentication rule specifies no actions. In a supplemental or alternative embodiment, enforcement points can execute a default action even if the authentication rule 400 specifies an action.
Authentication rule states 422 , 432 , and/or 442 , can be used in the selection and acquisition of the associated authentication rule triggers ( 420 , 430 , and 440 ) and rule actions ( 421 , 431 , and 441 ). For example, if the authentication rule 400 is in state ‘S1’, then only rule triggers 422 and 423 , and associated rule actions 421 and 431 will be selected for retrieval. Authentication rule states 422 , 432 , and 442 , can be stored in the rules server 141 and/or one or more device managers 145 . Authentication rule states 422 , 432 , and 442 , can also be associated with specific users, in which case a rule instance including the state can also be stored on the rules server 141 . Persistent-type authentication rules, which are those rules whose state can remain unchanged across sessions, can be represented by the authentication states 422 , 432 , and/or 442 , of an authentication rule 400 . In some embodiments, the authentication rule 400 can transition from one state to the another state when, for example, the authentication rule 400 is satisfied and/or an expiration period elapses. In some configurations, authentication states can be associated with either persistent-based or session-based authentication rules. State-transitioning allows for lifecycle management of the authentication rule 400 in a workflow.
Tables I-III below illustrate examples of different authentication rules. The elements of the Tables I and II are described using the exemplary authentication rule 400 of FIG. 4.
| TABLE I | |||
| Token Rule | |||
| Rule Data 410 | |||
| RuleName: RetailToken | |||
| User: RetailConsumers | |||
| Owner: Retail | |||
| OwnerType: Realm | |||
| Class: Session | |||
| State 422 | Rule Trigger 420 | Rule Action 421 | |
| S0 | <empty> | <empty> | |
| S1 | LoginMethod=U/PW | Reminder URL | |
| S2 | LoginMethod=U/PW | Token URL | |
| S2 | Realm=Retail | Token URL | |
| S3 | <empty> | <empty> | |
| TABLE II | ||
| Fraud Rule | ||
| Rule Data 410 | ||
| Rule Name: FraudIPBlock | ||
| Owner: StockTrader | ||
| OwnerType: Realm | ||
| Class: NavRestrict | ||
| Source: IP = {10.24.189.*, 189.1.1.10-189.1.2.21} | ||
| Rule Trigger 420 | Rule Action 421 | |
| <empty> | CallRepMessageURL | |
| TABLE III | |||
| User-Customizable Token Rule | |||
| Rule Data 410 | |||
| RuleName: CustomRetailToken | |||
| User: RetailConsumers | |||
| Owner: Retail | |||
| OwnerType: Realm | |||
| Class: Session | |||
| State 422 | Rule Trigger 420 | Rule Action 421 | |
| S0 | <empty> | <empty> | |
| S1 | LoginMethod=U/PW | Reminder URL | |
| S2 | LoginMethod=U/PW | RSAToken URL | |
| S2 | Realm=Retail | RSAToken URL | |
| S3 | LoginMethod=U/PW | VerToken URL | |
| S3 | Realm=Retail | VerToken URL | |
| S4 | <empty> | <empty> | |
Returning to the flowchart 200 illustrated in FIG. 2, service provisioning can include receiving, from a user, a request for a service ( 220 ), optionally generating a rules credential that includes one or more authentication rules ( 230 ), determining whether one or more authentication rules apply ( 240 ), processing one or more applicable authentication rules if they apply ( 250 ), determining if more authentication rules are applicable ( 260 ), and/or provisioning the requested service ( 260 ).
Receiving a request for a service ( 220 ) can include any request for information exchange with one or more servers 130 , the authentication server 140 , one or more device managers 145 , and/or one or more authentication monitors 160 . The request for service can be the initial login request to the authentication server 140 . The request for service can also take place after the initial login process, in which case the request can include a rules credential, discussed below.
Generating a rules credential that includes one or more authentication rules ( 230 ) can include generating a new rules credential (e.g., at initial login) and/or updating and re-generating the rules credential included in the request. A rules credential can include one or more authentication rules associated with a user based on selection criteria described in the authentication rule data section of an authentication rule (e.g., unique user identifiers and/or other characteristics). The rules server 141 can retrieve one or more authentication rules associated with the user. In a supplemental or alternative embodiment, a rules credential can include a compressed form of one or more authentication rules. For example, the compressed form can leave out one or more authentication actions in which case the enforcement point that evaluates the authentication rule will need to perform a default action.
In a supplemental or alternative embodiment, an authentication rule and/or a rules credential can also include the satisfaction state of an authentication rule. For example, for a session-based token authentication rule, a user can be required to enter in a token value once for each session. Initially, the generated rules credential will mark the token rule as unsatisfied. However, once the user correctly enters the appropriate token value, the token authentication rule can be marked as satisfied. Enforcement points will allow access to their services when they see that an authentication rule is satisfied, as described below. An authentication rule and/or a rules credential can also include a grouping identifier in relation to the satisfaction state of an authentication rule. For example, if a user is associated with more than one authentication rule that defines the same action and include the same group identifier, then when the user satisfies one authentication rule both authentication rules can be marked satisfied.
Table IV illustrates a satisfaction group example, in which three authentication rules have been defined including the same action (Token). The first authentication rule (for Retail resources) and the second authentication rule (for Institutional resources) are assigned to a common satisfaction group (‘0’). The third authentication rule (for personal transactions) is assigned to a separate group (‘1’). If the user satisfies either of the first or second authentication rules then the enforcement point can mark both satisfied in the rules credential for the user. The third authentication rule will remain unsatisfied until an enforcement point determines that its trigger set applies.
| TABLE IV | ||||
| Satisfaction Group Example | ||||
| Action | Group | TriggerSet | Instructions | |
| Token | 0 | realm=Retail | tokenURL | |
| Token | 0 | realm=Instit | tokenURL | |
| Token | 1 | trans=personal | tokenURL | |
A rules credential can be transferred to the requesting user (e.g., as a web cookie) such that the authentication rules are portable and can travel with the user. In such a scenario, a user can navigate from resource to resource on the network 100 without having to interact with a central authentication server for every request for a service. For example, the authentication server 140 can initially process an authentication rule included in a rules credential that applies during the login process. If a rule does not apply at login time, it can remain in the rules credential for later use by one or more authentication monitors 160 . As the user navigates resources around the network 100 , the authentication monitors 160 defending the resources in respective servers 130 can evaluate the authentication rules included in the rules credential and determine if they apply. When an authentication monitor 160 determines that an authentication rule applies, the authentication monitor 160 can execute the authentication rule.
A rules credential can also specify a processing order that one or more authentication rules should be processed. The order that one or more authentication rules are processed can be based on a priority code included in an authentication rule's data, the owner or sponsor of the authentication rule (e.g., provider/realm/client/user), the name of an action included in the authentication rule, or it can be based on one or more other elements of an authentication rule. For example, the rules credential can be generated such that all persistent-based rules are processed before all session-based rules. Rule priority can be an arbitrary value assigned by the creator of the authentication rules to order the authentication rule relative to other authentication rules.
An enforcement point can determine whether one or more authentication rules apply ( 240 ) based on information in one or more authentication rule triggers in an authentication rule and on information stored in the context of the enforcement point, as described above. If an authentication rule is applicable, the authentication rule is processed based on one or more authentication instructions specified by the authentication rule ( 250 ). After the authentication rule is processed, the rules credential can be re-acquired ( 230 ) to update any state change associated with the user. If un-processed authentication rules are left in the rules credential ( 260 ), the enforcement point performs elements ( 240 ) and ( 250 ). If no applicable authentication rules remain ( 260 ), then the requested service can be provisioned to the user ( 270 ).
FIGS. 5-25 illustrate flow diagrams depicting use case examples for authenticated service provisioning. The elements of the flow diagrams in FIGS. 5-25 are described using the exemplary network 100 of FIG. 1. In these examples, each resource is illustrated to reside on a separate server (e.g., one of servers 130 a - c ). However, one or more resources can also reside on the same server and the use case examples can equally be applied as such. consumer using a user device 120 logs in to the authentication server 140 . The initial request can include a user identification (e.g., username or userid), a password, and/or authentication context data. Authentication context data can include data characterizing: the authentication method, the access-channel, the access-location, the access-device, and/or the user role (e.g., customer, admin, etc.). The authentication server 140 forwards the user identification and authentication context data to the rules server 141 to retrieve the authentication rules associated with the consumer and/or the context. The rules server 141 can access a local or remote rules repository database to find the relevant authentication rules. The rules server 141 can generate a rules credential that includes the authentication rules. If more than one authentication rule was acquired, the rules server 141 can order the authentication rules in the rules credential based on, for example, a priority code, a type, a group code, and/or an action name of the authentication rules. The rules server 141 returns the rules credential to the authentication server 140 . Either the rules server 141 and/or the authentication server 140 can perform further processing on the rules credential (e.g., compression or rule ordering). The authentication server 140 returns the rules credential to the user 120 .
Use Case 2: Rule Update Acquisition
FIG. 6 illustrates a flow diagram depicting reacquiring a rules credential, which can include generating a new rules credential or updating an existing rules credential. The user 120 provides a rules credential and/or a rule satisfaction credential to the rules server 141 . The rule satisfaction credential can be generated by another component in the network 100 to indicate that one or more authentication rules in the rules credential have been satisfied or not. The request to the rules server 141 can also include authentication context data as described above. The rules server 141 can access a local or remote rules repository database to find the relevant authentication rules. The rules server 141 generates a new rules credential or updates the existing rules credential to include the authentication rules. The satisfaction state of the authentication rules in the new rules credential are set based on the rule satisfaction credential received from the user as well as the current satisfaction state in the previous rules credential. For example, a user that successfully entered a token passcode will receive a rule satisfaction credential that the rules server 141 will use to mark the token authentication rule as satisfied. The rules server 141 can also update the state of a device (e.g., a hard token as: enrolled, activated, or discarded) in the respective device manager 145 . The rules server 141 returns the rules credential to the authentication server 140 .
Use Case 3S: Session-Type Rule Fulfillment
FIG. 7 illustrates a flow diagram depicting the fulfillment of a session-type authentication rule. A user 120 can be redirected by a resource to a rule fulfillment server 130 a to enter, for example, a token passcode. The request includes a rules credential that, in turn, includes the authentication rule that is to be fulfilled. The authentication monitor 160 a evaluates the authentication rules included in the rules credential and determines that an authentication rule applies (i.e., is triggered) and is not satisfied. However, since the rule fulfillment server 130 a is the fulfillment point for the authentication rule, the authentication monitor 160 a includes a specific override for the authentication rule and allows the user 120 to access the rule fulfillment server 130 a . The rule fulfillment server 130 a challenges the user 120 as indicated by the authentication rule (e.g., requesting a token passcode to be entered). The user 120 returns a response to the challenge. The authentication monitor 160 a performs the same evaluation as described above and allows access to the rule fulfillment server 130 a . The rule fulfillment server 130 a evaluates the response and conveys the satisfaction state via a rule satisfaction credential (e.g., if the token passcode was correct then the rule satisfaction credential indicates the rule was satisfied). The rule fulfillment server 130 a transmits the rule satisfaction credential to the user 20 , who can then update their rules credential as illustrated in Case 2.
Use Case 3P: Persistent-Type Rule Fulfillment
FIG. 8 illustrates a flow diagram depicting the fulfillment of a persistent-type authentication rule. User Case 3P is identical to Use Case 3S except that after the rule fulfillment server 130 a determines that an authentication rule has been satisfied, the rule fulfillment server 130 a also sends a message to the rules server 141 indicating that the authentication rule has been satisfied. In other embodiments, the rule fulfillment server 130 a can send a message to a device manager 145 a indicating that the authentication rule has been satisfied (e.g., a device manager responsible for hard tokens can store state data indicating whether a hard token is activated or not).
Use Case 4: Rules Credential includes One Authentication Rule
FIG. 9 illustrates a flow diagram depicting the provisioning of a service when the rules credentials includes one authentication rule. The user 120 acquires the rules credential as illustrated in Case 1 . The user 120 requests the service from resource server 130 b . The request includes the rules credential. The resource authentication monitor 160 b determines that the authentication rule included in the rules credential applies and is not satisfied. The resource authentication monitor 160 b can also determine if any local override action exists. The default rule action redirects the user 120 to a fulfillment server URL. The user 120 fulfills the authentication rule as illustrated in Cases 3S or 3P depending on whether the rule is session-based or persistent-based. The user 120 a returns to the authentication monitor 160 b , which determines that the authentication rule applies and is satisfied. The authentication monitor 160 b admits the request for service to the resource server 130 b to provision the service.
Use Case 5: Sponsor Mandates a Non-Fulfilling Logging Rule for a User
FIG. 10 illustrates a flow diagram depicting a local non-fulfilling logging authentication rule. A sponsoring enterprise (e.g., a service provider) determines, for example, that a particular user 120 (e.g., JohnQAdams) may engage in fraudulent activity. The sponsor creates an authentication rule that requires every enforcement point to log additional information while processing the request. The authentication rule remains unsatisfied after fulfillment and requires the enforcement point 160 b defending a protected resource 130 b to log additional data about the request. Table V below illustrates the rule and enforcement contexts and the authentication rule associated with Case 5.
| TABLE V | |
| Use Case 5 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Web | |
| Source: 198.32.62.1 | |
| Agent: IE5.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Retail | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: Logging | |
| Rules Definition: | |
| Logging: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: N/A | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: FraudLog | |
| RuleType: Info | |
| GroupCode: 0 | |
| PriorityCode: 0 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: FraudLog | |
| OptionalOverride: None | |
Use Case 6: Sponsor Mandates a Non-Fulfilling Redirection Rule for a User
FIG. 11 illustrates a flow diagram depicting a non-fulfilling redirection authentication rule. A sponsoring enterprise (e.g., a service provider) determines, for example, that a particular user 120 (e.g., JohnQAdams) may engage in fraudulent activity. The sponsor creates an authentication rule that is enforced at all enforcement points (e.g., 160 b ) to defend a protected service by redirecting the user 120 to a different location 160 c . The authentication rule remains unsatisfied after fulfillment. The policy of the enforcement point defending the second enforcement point 160 c (EP2) overrides the default action and permits the request to enter. Table VI below illustrates the rule and enforcement contexts and the authentication rule associated with Case 6.
| TABLE VI | |
| Use Case 6 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext: EP1 | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Wholesale | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| EnforcementContext: EP2 | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Wholesale | |
| UserRole: Customer | |
| Time: 9:01am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride: | |
| RestrictSite: | |
| admit if unsat | |
| RuleAction: RestrictSite | |
| Rule Set (in eval order) | |
| Rule 1: Redirection | |
| Rules Definition: | |
| Redirection: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: N/A | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: Restrict | |
| RuleType: NavRestrict | |
| GroupCode: 0 | |
| PriorityCode: 0 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: AltURL | |
| OptionalOverride: None | |
Use Case 7: Sponsor Mandates a Global Hard Token Rule
FIG. 12 illustrates a flow diagram depicting service provisioning using a global hard token rule. A sponsor creates a mandatory hard token authentication rule for all users of the sponsor, including user 120 . The authentication rule applies when any user accesses any service (e.g., retail account summary at server 130 a ). The user 120 must satisfy the authentication rule once in a session. If the authentication rule is not satisfied, the authentication rule requires the user 120 to provide a hard token generated one-time PIN when the user visits the protected resource 130 a . If the user 120 correctly inputs the appropriate passcode at token server 130 b , then the user's rules credential can be updated, as illustrated in Case 2, to mark the hard token rule satisfied. The user 120 can then access the requested service at server 130 a . Table VII below illustrates the rule and enforcement contexts and the authentication rule associated with Case 7.
| TABLE VII | |
| Use Case 7 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Wholesale | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: HardToken | |
| Rules Definition: | |
| HardToken: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: N/A | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: HTokenAct | |
| RuleType: Session | |
| GroupCode: 0 | |
| PriorityCode: 1 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: HTokenURL | |
| OptionalOverride: None | |
Use Case 8: Sponsor Offers Users Option to Use a Global Hard Token Rule
FIG. 13 illustrates a flow diagram depicting service provisioning using an optional global hard token rule. A sponsor creates an optional hard token authentication rule for all users that enroll with the sponsor, including user 120 , who has activated their hard token. The authentication rule applies when any user accesses any service (e.g., Employee Services Company (ESCo) Enrollment Server 130 a ). The user 120 must satisfy the authentication rule once in a session. If the authentication rule is not satisfied, the authentication rule requires the user 120 to fulfill the authentication rule at hard token server 130 b . The hard token authentication monitor 160 b determines that the rule applies and is not satisfied. However, the hard token authentication monitor 160 b includes an override in this case and provides access to the hard token server 130 b , which challenges the user 120 to provide a hard token generated one-time PIN. If the user 120 correctly inputs the appropriate passcode at token server 130 b , then the user's rules credential can be updated, as illustrated in Case 2, to mark the hard token rule satisfied. The user 120 can then access the requested enrollment service at Employee Services Company server 130 a . Table VIII below illustrates the rule and enforcement contexts and the authentication rule associated with Case 8.
| TABLE VIII | |
| Use Case 8 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: NBCust | |
| AuthBusUnit: ESCo | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: NBCust | |
| AuthBusUnit: ESCo | |
| Owner: ESCo | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: HardToken | |
| Rules Definition: | |
| HardToken: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: N/A | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: HTokenAct | |
| RuleType: Session | |
| GroupCode: 0 | |
| PriorityCode: 1 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: HTokenURL | |
| OptionalOverride: None | |
Use Case 9: Sponsor Mandates a User-Configurable Global Hard Token Rule
FIG. 14 illustrates a flow diagram depicting service provisioning using an user-configurable global hard token rule. A sponsor can create one or more hard token authentication rules to be used with different hard token vendors (e.g., RSA, Verisign, etc.). The sponsor can allow users enrolled for hard tokens to select what type of hard token to use. User 120 has selected hard token A and has activated their hard token such that the payload instruction in the authentication rule directs the user to hard token A server 130 b . In this case, the authentication rule is mandated by the sponsor, however the sponsor can also make the rule optional to the user 120 . Table IX below illustrates the rule and enforcement contexts and the authentication rule associated with Case 9.
| TABLE IX | |
| Use Case 9 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Retail | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: HardTokenA | |
| Rules Definition: | |
| HardTokenA: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: N/A | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: HTokenAAct | |
| RuleType: Session | |
| GroupCode: 0 | |
| PriorityCode: 1 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: HTokA URL | |
| OptionalOverride: None | |
Use Case 10a: Sponsor Group Mandates a Hard Token Rule
FIG. 15 illustrates a flow diagram depicting service provisioning using a group mandated hard token rule. A group of a sponsor (e.g., a client company of an employee services company) creates a mandatory hard token rule for all employees, including user 120 a , of the client company. The authentication rule applies whenever the users enter via the group's unit authentication method or when the users visit a protected resource of the group. The user 120 a must satisfy the authentication rule only once in an authentication session. The group of the sponsor, or the sponsor, provides a list of the employees and the sponsor can create this authentication rule for each of the employees. Table X below illustrates the rule and enforcement contexts and the authentication rule associated with Case 10.
| TABLE X | |
| Use Case 10 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: NBPart | |
| AuthBusUnit: ESCo | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: NBPart | |
| AuthBusUnit: ESCo | |
| Owner: ESCo | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: HardToken | |
| Rules Definition: | |
| HardToken: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: ESCo | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: HTokenAct | |
| RuleType: Session | |
| GroupCode: 0 | |
| PriorityCode: 1 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: HTokenURL | |
| OptionalOverride: None | |
Use Case 10 b: Sponsor Group Mandates a Hard Token Rule
FIG. 16 illustrates a flow diagram depicting service provisioning using the group mandated hard token rule of Use Case 10a. However, the user 120 b is not an employee of the Employee Services Company (ESCo). In this case, the rules credential does not include the authentication rule from Use Case 10a. Therefore, the ESCo Account authentication monitor 160 a allows the user 120 to access the ESCo Account server 130 a.
Use Case 11: Sponsor Group Offers an Optional Hard Token Rule
FIG. 17 illustrates a flow diagram depicting service provisioning using a group-sponsored optional hard token rule. A group of a sponsor (e.g., a client company of an employee services company) creates an optional hard token rule for all employees, including users 120 a and 120 b , of the client company. User 120 a is enrolled in the hard token, and service provisioning follows the flow diagram illustrated in Case 8. User 120 b , while an employee in a group that is a plan sponsor in Employee Services Company (ESCo), is not enrolled in the hard token. Therefore, the rules credential for user 120 b does not include the hard token authentication rule and the ESCo Account authentication monitor 160 a allows the user 120 b to access the ESCo server 130 a . Likewise, for a user 120 c that is not a member of a group sponsor in ESCo, their rules credential will not include a hard token authentication rule. Table XI below illustrates the rule and enforcement contexts and the authentication rule associated with Case 11.
| TABLE XI | |
| Use Case 11 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: NBPart | |
| AuthBusUnit: ESCo | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext | |
| AuthMethod: NBPart | |
| AuthBusUnit: ESCo | |
| Owner: ESCo | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: HardToken | |
| Rules Definition: | |
| HardToken: | |
| TriggerSets(inclusive) | |
| Channel: N/A | |
| UserRole: N/A | |
| BusUnit: ESCo | |
| Time: N/A | |
| Day: N/A | |
| Interval: N/A | |
| AuthMethod: N/A | |
| ServiceType: N/A | |
| RuleActionName: HTokenAct | |
| RuleType: Session | |
| GroupCode: 0 | |
| PriorityCode: 1 | |
| Satisfaction: NotSatis | |
| DefaultFulAction: Redirect | |
| FulfillmentLoc: HTokenURL | |
| OptionalOverride: None | |
Use Case 12: User has Multiple Rule Types
FIGS. 18A-B illustrate a flow diagram depicting service provisioning when a user has three authentication rules: logging, hard token, and forced ACI. The rules are ordered in the rules credential such that the logging rule is evaluated first at each enforcement point, followed by evaluation of the hard token rule, and then evaluation of the forced ACI rule. The user 120 requests an account summary service from ESCo Account server 130 a . The ESCo authentication monitor 160 a determines that the logging rule applies and logs information about the session. Next, the ESCo authentication monitor 160 a determines that a hard token rule applies and is not satisfied. The user 120 is redirected to fulfill the hard token authentication rule. The hard token authentication monitor 160 b also determines that the logging rule applies and logs information on the session. Next, the hard token authentication monitor 160 b determines that the hard token authentication rule applies and is not satisfied. However, since the hard token authentication monitor 160 b protects the server 130 b that is associated with fulfillment of the hard token authentication rule, an override exists that allows the user 120 to access the hard token server 130 b.
As illustrated in FIG. 18B, the user 120 returns to the ESCo authentication monitor 160 a , which still determines that the logging rule applies and logs information about the session. The ESCo authentication monitor 160 a now, however, determines that the hard token rule is satisfied and evaluates the next authentication rule in the rules credential. The forced ACI authentication rule is a persistent rule that forces the user 120 to change their ID if their current ID is set to be their social security number (SSN). The user 120 is redirected to change their ID (i.e., fulfill the forced ACI authentication rule). The SSN ID authentication monitor 160 c determines that the logging rule applies and logs information on the session, and that the hard token rule applies but is satisfied. Next, the SSN ID authentication monitor 160 c determines that the forced ACI authentication rule applies, is not satisfied, but that an override exists for the rule to allow access to the the SSN ID server 130 c . The user 120 is challenged to change their ID and the forced ACI rule is satisfied if the ID is not the user 120 's SSN. The user 120 is subsequently allowed to access their account summary at server 130 a . Table XII below illustrates the rule and enforcement contexts and the authentication rule associated with Case 12.
| TABLE XII | |
| Use Case 12 | |
| RuleAcquisitionContext | |
| UserID: GeneralUser | |
| AuthMethod: NBPlanAdmin | |
| AuthBusUnit: ESCo | |
| Channel | |
| Type: Any | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Admin | |
| EnforcementContext | |
| AuthMethod: NBPlanAdmin | |
| AuthBusUnit: ESCo | |
| Owner: ESCo | |
| UserRole: Admin | |
| Time: 11am | |
| Day: Thursday | |
| Expiration: None | |
| Channel: Any | |
| ServiceType: Any | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: Logging | |
| Rule 2: HardToken | |
| Rule 3: ForcedACI | |
| Rules Definition: | |
| Logging: (see Table XIX) | |
| HardToken: (see Table XI) | |
| ForcedACI: (see Table XV) | |
Use Case 13: User has Multiple Rule Types Triggering in Different Business Units
FIGS. 19A-B illustrates a flow diagram depicting service provisioning when a user has multiple rule types triggering in different business units. For various reasons, a user that is both a normal customer and also an employee of a client organization can have acquired a set of rules that comprise: a non-fulfilling logging rule (due to suspicious browser characteristics that triggers in Retail and ESCo), a hard token rule (due to customer opt-in that triggers only in Retail), and a non-SSN ID (forced ACI) rule (due to client organization mandate that triggers only in ESCo). FIGS. 19A-B illustrate how the rules are triggered and enforced for Use Case 13 as the user 120 navigates the network 100 . Table XIII below illustrates the rule and enforcement contexts and the authentication rule associated with Case 13.
| TABLE XIII | |
| Use Case 13 | |
| RuleAcquisitionContext | |
| UserID: GeneralUser | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Any | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext: EP1 | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: Retail | |
| UserRole: Customer | |
| Time: 11am | |
| Day: Thursday | |
| Expiration: None | |
| Channel: Any | |
| ServiceType: Any | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
| Rule Set (in eval order) | |
| Rule 1: Logging | |
| Rule 2: HardToken | |
| Rule 3: ForcedACI | |
| Rules Definition: | |
| Logging: (see Table XIX) | |
| HardToken: (see Table XI) | |
| ForcedACI: (see Table XV) | |
| EnforcementContext: EP2 | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: ESCo | |
| UserRole: Customer | |
| Time: 11:05am | |
| Day: Thursday | |
| Expiration: None | |
| Channel: Any | |
| ServiceType: Any | |
| LocalOverride(s): None | |
| RuleActionPresence: None | |
Use Case 14: Hard Token User is Challenged, Navigates Away to Non-Protected Site
FIG. 20 illustrates a flow diagram depicting service provisioning when a user is challenged for a hard token and navigates away to a non-protected site. A client organization of an enterprise business unit (e.g. a client of ESCo Services) requires their employees to use a hard token to enter the Enterprise Business Unit. When such a user attempts to visit any protected resource of the Business Unit, and the rule is not satisfied, the rule challenges the user to provide a hard token generated one-time PIN. In this example, the user 120 declines to enter a token value and navigates away to another Enterprise Business Unit at which they have a relationship and at which the hard token rule does not apply. They are allowed entry to the other Enterprise Business Unit. FIG. 20 illustrates how the rules are triggered and enforced for Use Case 14 as the user 120 navigates the network 100 . Table XIV below illustrates the rule and enforcement contexts and the authentication rule associated with Case 14.
| TABLE XIV | |
| Use Case 14 | |
| RuleAcquisitionContext | |
| UserID: JohnQAdams | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Channel | |
| Type: Web | |
| Source: 127.0.0.1 | |
| Agent: IE6.0.2019.7 | |
| UserRole: Customer | |
| EnforcementContext: EP1 | |
| AuthMethod: RetailCust | |
| AuthBusUnit: Retail | |
| Owner: ESCo | |
| UserRole: Customer | |
| Time: 9am | |
| Day: Wednesday | |
| Expiration: None | |
| Channel: Web | |
| ServiceType: PersonalData | |
| LocalOverride(s): None | |