US10862681B2 - Optimized sign out for single account services - Google Patents
Optimized sign out for single account services Download PDFInfo
- Publication number
- US10862681B2 US10862681B2 US15/479,197 US201715479197A US10862681B2 US 10862681 B2 US10862681 B2 US 10862681B2 US 201715479197 A US201715479197 A US 201715479197A US 10862681 B2 US10862681 B2 US 10862681B2
- Authority
- US
- United States
- Prior art keywords
- account
- user
- sign
- service
- signed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
- 238000000034 method Methods 0.000 claims description 53
- 230000009471 action Effects 0.000 claims description 45
- 239000013598 vector Substances 0.000 claims description 12
- 238000012549 training Methods 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 9
- 238000010801 machine learning Methods 0.000 claims description 5
- 238000002372 labelling Methods 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 23
- 238000012545 processing Methods 0.000 description 23
- 230000008520 organization Effects 0.000 description 9
- 238000003066 decision tree Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- 230000002730 additional effect Effects 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000012706 support-vector machine Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/316—User authentication by observing the pattern of computer usage, e.g. typical user behaviour
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
- G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
Definitions
- a service typically maintains a separate set of information.
- an electronic mail service stores emails sent and received using each account.
- the user provides credentials such as user name and password.
- the user name typically uniquely identifies the account, and the password is used to authenticate the user when the user later signs in to the account.
- Many services employ an identity provider service to perform the authentication of users.
- the service directs the user to the identity provider service to input the user name and password for the account.
- the identity provider service maintains a database of user credentials for the service.
- the service directs the user to the identity provider service.
- the user provides the credentials to the identity provider service.
- the identity provider service verifies the credentials against those in the database. If the credentials are verified, the identity provider service provides to the service a security token for the account (e.g., indirectly via the device of the user).
- the security token is signed by the identity provider service and is evidence that the user has been authenticated as providing the proper credentials for the account.
- the service can check the signature of the security token to determine that it was signed by the identity provider service and check the content of the security token to confirm that the user has been authenticated.
- the service then allows the user to access the account.
- Many services allow a client (e.g., browser or device) to be signed in to only one account at a time. For example, a user currently signed in to a first account of an email service using a certain browser may not be able to sign in to a second account of that email service using that browser without first signing out of the first account. If the user wanted to be signed in to both accounts simultaneously, the user might need to access the email service using a different browser or a different device.
- Such services are referred to as “single account services” because they allow only one account to be signed in to at a time from each client. Although it may be possible to modify each single account service to support sign in by multiple accounts from a single client, such modification would very time-consuming and might be prohibitively expensive. Moreover, many single account services may be considered to be legacy systems that are no longer supported by their developers and thus cannot practically be modified.
- an optimized sign out identity provider (“OSO-IP”) service is provided to provide an optimized sign out experience for a user accessing a single account service.
- the OSO-IP service designates a first account of a service as signed in based on first credentials provided by a user.
- the OSO-IP service provides a first security token for the first account to the service.
- the OSO-IP service determines whether the user wants to switch to a second account of the service.
- the OSO-IP service designates the second account as signed in based on second credentials provided by the user.
- the OSO-IP service provides a second security token for the second account to the service.
- the OSO-IP service also designates the first account as soft signed out so that the user can switch to the first account without re-providing the first credentials.
- FIGS. 1A-1D are user interface elements that illustrate the requesting of user intent when signing out of an account in some embodiments.
- FIG. 2 is a state diagram that illustrates the states of accounts of the OSO-IP service in some embodiments.
- FIG. 3 is a communications flow diagram that illustrates communications between a client, an SA service, and an OSO-IP service in some embodiments.
- FIG. 4 is a flow diagram that illustrates high-level processing of a component of the OSO-IP service in some embodiments.
- FIG. 5 is a block diagram that illustrates components of the OSO-IP service in some embodiments.
- FIG. 6 is a flow diagram that illustrates processing of a sign in component of the OSO-IP service in some embodiments.
- FIG. 7 is a flow diagram that illustrates processing of a sign out notification component of the OSO-IP service in some embodiments.
- FIG. 8 is a flow diagram that illustrates processing of the sign out component of the OSO-IP service in some embodiments.
- FIG. 9 is a flow diagram that illustrates processing of a switch component of the OSO-IP service in some embodiments.
- FIG. 10 is a flow diagram that illustrates processing of a generate user experience component of the OSO-IP system in some embodiments.
- FIG. 11 is a flow diagram that illustrates processing of a learn user experience component of the OSO-IP service in some embodiments.
- FIG. 12 is a flow diagram that illustrates processing of a generate learned user experience component of the OSO-IP service in some embodiments.
- an optimized sign out (“OSO”) system allows a user, who has signed in to a first account of a single account (“SA”) service and then signed out of the SA service to sign in to a second account of the single account service, to sign back in to the first account without having to provide first credentials for the first account.
- SA single account
- the OSO system may be implemented as an identity provider (“OSO-IP”) service that provides authentication services for SA services.
- OSO-IP identity provider
- the user provides first credentials (e.g., user name and password) for the first account to the OSO-IP service.
- the OSO-IP service verifies that the first credentials are valid for the SA service and sends a first security token to the SA service.
- the OSO-IP service also designates the first account as having been signed in.
- the SA service verifies the first security token and completes the sign-in to the first account of the SA service. The user can then interact with the SA service using the first account.
- the user may want to sign in to a second account with the SA service using the same client.
- the user may have multiple email accounts with an email service or may have both a low-privilege staff account and a high-privilege administrator account with an application of an organization.
- the user needs to sign out of the first account.
- the SA service signs the user out of the first account and then sends a sign out notification to the OSO-IP service so that the OSO-IP service will know that the user has signed out of the first account in order to remove state information relating to the sign-in to the first account.
- the OSO-IP service makes a determination as to whether to perform the typical sign out processing for the first account or to “interrupt” the sign out process to determine the user's intent by requesting the user to indicate whether the user wants to sign in to a second account.
- the request may also allow the user to provide second credentials for the second account and to indicate whether the user may want to sign back in to the first account. For example, if the client is a browser, the request may be presented to the user in a pop-up window with a checkbox for the user to indicate that the user may want to sign back in to the first account and a data entry area for entry of the second credentials for the second account.
- the OSO-IP service When the OSO-IP service receives the response to the request, if the response indicates that the user does not want to sign in to another account, then the OSO-IP service performs the conventional processing for signing out of the first account. If, however, the response indicates that the user wants to sign in to a second account, the OSO-IP service verifies the second credentials provided in the response for the second account and sends a second security token to the SA service. The OSO-IP service also designates the second account as being signed in. Upon receiving the second security token, the SA service verifies the second security token and completes the sign-in to the second account of the SA service. The user can then interact with the SA service using the second account.
- the OSO-IP service designates the first account as being “soft” signed out and does not perform its normal processing for a sign-out, that is, removing state information for the first account. Rather, the OSO-IP service maintains the state information (e.g., the first security token). If, however, the response indicates that the user does not want to sign back in to the first account, the OSO-IP service designates the first account as being signed out and performs its normal processing for a sign-out.
- the term “soft sign out” indicates the user has signed out of the first account with the SA service but that the OSO-IP service has saved state information so that the user can be signed back in to the first account without the user re-providing the first credentials.
- the term “sign out” indicates the user has signed out of the first account with the SA service and cannot be signed back in without re-providing the first credentials.
- the OSO-IP service receives the sign out notification as part of the SA service signing the user out of the second account. If the OSO-IP service determines that the client is soft signed in to the first account, the OSO-IP service may request the user to indicate whether the user wants to sign back in to the first account, referred to as “switching” accounts. If the user indicates to switch accounts, the OSO-IP service retrieves the first security token and sends it to the SA service, which signs the user back in to the first account. The OSO-IP service designates the first account as being signed in and the second account as being either soft signed out or signed out based on a determination as to whether the user might want to sign back in to the second account. In this way, the OSO-IP service provides an environment in which it appears to a user that they are signed in to multiple accounts of an SA service via a single client.
- FIGS. 1A-1D are user interface elements that illustrate the requesting of user intent when signing out of an account in some embodiments.
- User interface element 110 is an example of the OSO-IP service requesting a user to indicate their intent when signing out of account A. If the user wants to sign in to another account, the user enters the credentials for the other account in sign in area 111 . If the user wants to sign out of account A, the user selects checkbox 112 . The user selects the enter button 113 send their intent.
- User interface element 110 allows the user to sign out of account A and not sign in to any other account, sign out of account A and sign in to another account, or to stay what appears to be signed in to account A and to sign in to another account.
- User interface element 120 is an example of the OSO-IP service requesting a user to indicate their intent when assigning out of account B.
- the user is signed in to account B and is soft signed out of account A.
- the user has the option of signing out of both account A and account B using checkbox 121 , signing out of account B using checkbox 122 , switching to be signed in to account A using checkbox 123 , or signing in to a new account using the sign in area 124 .
- the user selects various combinations of the checkboxes to express their intent.
- the user selects the enter button 125 to transmit their intent.
- User interface element 130 is an example of the OSO-IP service requesting a user to indicate their intent in some embodiments.
- User interface element 130 is a simplified version of user interface element 120 in that the user is given only the option to express their intent to switch to account A or to sign out of both account A and account B.
- the OSO-IP service may use machine learning to infer a user's likely intent. For example, if a user normally switches between accounts when accessing a certain SA service, the OSO-IP service may elicit the user's intent using user interface element 130 , which is simpler than user interface element 120 .
- Checkbox 131 may be a checked by default to indicate the likely user intent.
- Checkbox 132 may be deemphasized as it is unlikely to be the user intent, but is needed when the user ultimately wants to sign out of the accounts. The user simply selects the enter button 133 to transmit their intent to switch to account A. User interface element 130 does not, however, allow the user to sign in to another account. To sign in to another account, the user would need to select checkbox 132 (e.g., automatically de-selecting checkbox 131 ) to sign out of account A and account B and then access the sign in page for the SA service to sign in to the other account.
- checkbox 132 e.g., automatically de-selecting checkbox 131
- User interface element 140 is an example of the OSO-IP service requesting a user to indicate their intent in some embodiments.
- User interface element 140 allows the user to sign out of account B and switch to account A using checkbox 141 or to sign out of both accounts using checkbox 142 .
- the user selects the enter button 143 to transmit their intent.
- User interface element 140 may be useful when, for example, the user has a low-privilege account A and a high-privilege account B with an application of an organization.
- the organization may want to require all high-privilege accounts to be automatically signed out for security reasons. For example, if a device is shared by multiple employees, such as in a retail store, the automatic signing out of high-privilege accounts may be desirable, for example, when multiple employees share the same low-privilege account.
- FIG. 2 is a state diagram that illustrates the states of accounts of the OSO-IP service in some embodiments.
- a state diagram 200 includes states 201 - 205 .
- State 201 indicates that no accounts are signed in.
- State 202 indicates that only account A is signed in.
- State 203 indicates that only account B is signed in.
- State 204 indicates that account A is signed in and that account B is soft signed out.
- State 205 indicates that account B is signed in and that account A is soft signed out.
- the lines between the states indicate events causing transition from one state to another state. For example, if the current state is 201 and the user signs in to account A, then line 210 indicates the transition to state 202 .
- line 220 indicates the transition from state 202 to state 205 .
- line 230 indicates the transition from state 205 to state 201 .
- FIG. 3 is a communications flow diagram that illustrates communications between a client, an SA service, and an OSO-IP service in some embodiments.
- Communications 340 indicate client 310 signing in to account A of SA service 320 that uses OSO-IP service 330 as an identity provider service.
- the client sends 341 a sign in request to the SA service. Since the SA service uses the OSO-IP service, it sends 342 an authentication request via the client to the OSO-IP service.
- the OSO-IP service sends 343 a request for credentials to the client (e.g., a sign in web page).
- the client sends 344 the credentials to the OSO-IP service.
- the OSO-IP service verifies the credentials for account A and sends 345 a security token for account A to the SA service via the client.
- the SA service completes the signing in.
- the user can then interact 346 with the SA service using account A.
- Communications 350 indicate the client signing in to account B with a soft sign-out for account A.
- the client sends 351 a sign out request to the SA service.
- the SA service designates account A as signed out and sends 352 a sign out notification to the OSO-IP service via the client.
- the OSO-IP service sends 353 an intent request to the client.
- the client sends 354 the credentials for account B along with an indication to stay signed in to account A.
- the OSO-IP service verifies the credentials and indicates that account B is signed in and that account A is soft signed out.
- the OSO-IP service then sends 355 a security token for account B to the SA service via the client.
- the SA service completes the sign-in for account B.
- the client can then interact 356 with the SA service using account B.
- Communications 360 indicate the switching from being signed in to account B to being signed in to account A.
- the client sends 361 a sign out request to the SA service.
- the SA service designates account B as signed out and sends 362 a sign out notification to the OSO-IP service.
- the OSO-IP service sends 363 an intent request to the client.
- the client sends 364 an indication that the intent is to switch to account A.
- the OSO-IP service designates account A as now signed in and account B as being soft signed out and sends 365 the security token for account A to the SA service via the client.
- the SA service signs the user in to account A using the security token.
- the client can then interact 366 with the SA service.
- Communications 370 indicate the switching to account B along with signing out from account A.
- the client sends 371 a sign out request to the SA service.
- the SA service designates account A as signed out and sends 372 a sign out notification to the OSO-IP service via the client.
- the OSO-IP service sends 373 an intent request to the client.
- the client sends 374 an indication that the intent is to switch to account B and to sign out of account A.
- the OSO-IP service designates account B as signed in and account A as signed out and sends 375 the security token for account B to the SA service via the client.
- the SA service signs the user in to account B based on the security token.
- the client then interacts 376 with the SA service using account B.
- FIG. 4 is a flow diagram that illustrates high-level processing of a component of the OSO-IP service in some embodiments.
- a component 400 illustrates the signing in to account A and then signing in to account B and designating account A as soft signed out.
- the component designates account A as signed in based on credentials received from the client for account A.
- the component sends a security token for account A to the SA service.
- the component receives a sign out notification from the SA service indicating that the user has requested to sign out of account A.
- decision block 404 if the intent of the user is to switch accounts, then the component continues at block 405 , else the component continues at block 408 .
- the component designates account B as signed in based on verification of the credentials.
- the component sends a security token for account B to the service.
- the component designates account A as being soft signed out and completes.
- the component designates account A as signed out and completes.
- FIG. 5 is a block diagram that illustrates components of the OSO-IP service in some embodiments.
- OSO-IP service 500 , client computer 520 , and SA service computer 530 are connected to communications channel 540 .
- the OSO-IP service includes a sign in request component 501 , a sign out notification component 502 , a sign in component 503 , a sign out component 504 , a generate user experience component 505 , a switch component 506 , a generate learned user experience component 507 , and a learn user experience component 508 .
- the OSO-IP service also includes a credential store 509 , a sign out log 510 , and a user experience classifier 511 .
- the sign in request component processes a sign in request from the SA service by invoking the sign in component.
- the sign out notification component processes a sign out notification received from the SA service by invoking the sign out component.
- the sign out component may invoke the generate user experience component to generate the user interface element to present to the user that has requested to sign out.
- the sign out component may also invoke the switch component to effect the switching from one account to another account.
- the generate learned user experience component is invoked to generate a user experience using a user experience classifier.
- the user experience classifier is trained using the learn user experience component based on data collected when users express their intent and stored in the sign out log.
- the credential store stores the credentials for the accounts of the SA service.
- the client computer includes a browser 521 , which is the client that the user uses to interact with the SA service.
- the SA service computer includes the SA service 531 .
- the computing systems also referred to as computer systems, used by the OSO-IP service may include a central processing unit, input devices, output devices (e.g., display devices and speakers), storage devices (e.g., memory and disk drives), network interfaces, graphics processing units, accelerometers, cellular radio link interfaces, global positioning system devices, and so on.
- a computing system may include multiple devices such as servers of a data center, massively parallel systems, and so on.
- the computing systems may access computer-readable media that include computer-readable storage media and data transmission media.
- the computer-readable storage media are tangible storage means that do not include a transitory, propagating signal. Examples of computer-readable storage media include memory such as primary memory, cache memory, and secondary memory (e.g., DVD) and other storage.
- the computer-readable storage media may have recorded on them or may be encoded with computer-executable instructions or logic that implements the OSO-IP service.
- the data transmission media are used for transmitting data via transitory, propagating signals or carrier waves (e.g., electromagnetism) via a wired or wireless connection.
- the OSO-IP service may be described in the general context of computer-executable instructions, such as program modules and components, executed by one or more computers, processors, or other devices.
- program modules or components include routines, programs, objects, data structures, and so on that perform tasks or implement data types.
- the functionality of the program modules may be combined or distributed as desired in various embodiments.
- aspects of the OSO-IP service may be implemented in hardware using, for example, an application-specific integrated circuit (ASIC).
- ASIC application-specific integrated circuit
- FIG. 6 is a flow diagram that illustrates processing of a sign in component of the OSO-IP service in some embodiments.
- a sign in component 600 is invoked to process a request to sign in to an account based on provided credentials.
- the component verifies the credentials based on the credential store.
- decision block 602 if the credentials have been verified, then the component continues at block 603 , else the component continues at block 608 .
- the component generates a security token for the account.
- the component designates the account as being signed in.
- decision block 605 if another account was signed in, then the component continues at block 606 , else the component continues at block 607 .
- the component designates the other account as soft signed out and continues at block 607 .
- the component sends the security token to the SA service and completes.
- the component sends a failed message to the client and completes.
- FIG. 7 is a flow diagram that illustrates processing of a sign out notification component of the OSO-IP service in some embodiments.
- a sign out notification component 700 is invoked when the OSO-IP service receives a sign out notification from an SA service.
- the component invokes a generate user experience component to generate a user interface element to present to the user.
- decision block 702 if a user interface element was generated, then the component continues at block 704 , else the component continues at block 703 .
- a user interface element may not be generated, for example, if a company has designated that certain accounts should always be signed out.
- the component invokes a sign out component passing an indication that all accounts are to be signed out and then completes.
- the component sends an intent request to the user that includes the generated user interface element.
- the component receives the intent response from the client.
- decision block 706 if the intent is to sign out of all accounts, then the component continues at block 707 , else the component continues at block 708 .
- block 707 the component invokes the sign out component passing an indication to sign out of all accounts and then continues at block 712 .
- decision block 708 if the intent is to sign out of a single account, then the component continues at block 709 , else the component continues at block 710 .
- the component invokes the sign out component indicating to sign out of a single account and then continues at block 710 .
- decision block 710 if the intent is to switch accounts, then the component continues at block 711 , else the component continues at block 712 .
- the component invokes a switch component to switch accounts and then completes.
- the component if the intent is to sign in to an account, then the component continues at block 713 , else the component completes.
- the component invokes the sign in component passing an indication of the credentials and then completes.
- FIG. 8 is a flow diagram that illustrates processing of the sign out component of the OSO-IP service in some embodiments.
- a sign out component 800 is invoked to sign out of a single account or all accounts as specified by a parameter.
- decision block 801 if all accounts are to be signed out, then the component continues at block 803 , else the component continues at block 802 .
- block 802 the component designates the account that is currently designated as signed in as signed out and removes any state information and then completes.
- the component selects the next account.
- decision block 804 if all the accounts have already been selected, then the component completes, else the component continues at block 805 .
- the component designates the selected account as signed out and removes any state information for the account and then loops to block 803 to select the next account.
- FIG. 9 is a flow diagram that illustrates processing of a switch component of the OSO-IP service in some embodiments.
- a switch component 900 is invoked to switch to another account.
- the component designates the signed in account, if any, as being soft signed out.
- the component designates the other account as signed in.
- the component sends a security token for the other account to the SA service and then completes.
- FIG. 10 is a flow diagram that illustrates processing of a generate user experience component of the OSO-IP system in some embodiments.
- a generate user experience component 1000 is invoked to generate a user interface element for eliciting a user's intent.
- decision block 1001 if the SA service has designated an automatic sign out for all sign out requests, then the component completes returning an indication that a user interface element was not created, else the component continues at block 1002 .
- the component selects a standard user interface element.
- decision block 1003 if the IP address of the client is untrustworthy, then the component continues at block 1004 , else the component continues at block 1005 .
- the component selects a user interface element with a default set to sign out of the currently signed in account and then completes.
- An IP address may be considered untrustworthy, for example, if the client computer may be used by the public such as in a library.
- decision block 1005 if there is an account designated as being soft signed out, then the component continues at block 1006 , else the component continues at block 1007 .
- block 1006 the component selects a user interface element with an option to switch to the soft signed out account and then completes.
- decision block 1007 if the user interface element has been learned for the user (e.g., using a trained classifier), then the component continues at block 1008 , else the component continues at block 1009 .
- the component selects the user interface element learned for the user and then completes.
- decision block 1009 if a user interface element has been learned for the organization, then the component continues at block 1010 , else the component continues at block 1011 .
- the component selects the user interface element learned for the organization and then completes.
- decision block 1011 if the organization has a standard user interface element, then the component continues at block 1012 , else the component completes.
- block 1012 the component selects the user experience for the organization and then completes.
- FIG. 11 is a flow diagram that illustrates processing of a learn user experience component of the OSO-IP service in some embodiments.
- a learn user experience component 1100 is invoked to train a classifier to select a user interface element that is appropriate.
- the component collects logs of actions taken by users in responding to requests for their intent. For example, for each intent that is expressed, the log may contain an entry that indicates the action selected by the user, the user, the SA service, the organization, and so on.
- the component loops generating training data to use in training the classifier.
- the component selects the next entry of the log.
- the component In decision block 1103 , if all the entries have already been selected, then the component continues at block 1107 , else the component continues at block 1104 .
- the component In block 1104 , the component generates a feature vector for the selected entry.
- the feature vector may include information such as the identity of the service, the user name of the credentials, demographic information about the user, the organization, privilege level of the account, IP address of the client, client device type, and so on.
- the component extracts the action from the action that the user took.
- the component labels a feature vector with the action and then loops to block 1102 to select the next entry.
- the component trains a classifier using the training data.
- the classifier may be probability-based in that, when provided with a feature vector, it provides a probability for each of the likely actions.
- FIG. 12 is a flow diagram that illustrates processing of a generate learned user experience component of the OSO-IP service in some embodiments.
- a generate learned user experience component 1200 is invoked to generate a user experience using a trained classifier.
- the component generates a feature vector based on the current request to sign out of an account.
- the component applies a classifier to the feature vector.
- the component selects the action with the highest probability.
- the component adds that action to the user interface element.
- decision block 1205 if the action is above a threshold probability for marking the action as a default action, then the component continues at block 1206 , else the component continues at block 1207 .
- the component marks the action to be the default action, for example, by checking a checkbox, and then continues at block 1207 .
- the component loops adding additional actions to the user interface element.
- the component selects the next action in probability order.
- decision block 1208 if the probability of the selected action is below the threshold for adding to the user interface element or all the user interface elements have already been selected, then the component continues at block 1210 , else the component continues at block 1209 .
- the component adds the selected action to the user interface element and loops to block 1207 to select the next action.
- decision block 1210 if a sign out all action is to be added to the user interface element, then the component continues at block 1211 , else the component completes. In block 1211 , the component adds a sign out all action to the user interface element and then completes.
- the OSO-IP service may use various machine learning techniques to generate a classifier, such as a support vector machine, a Bayesian network, a Na ⁇ ve Bayesian network, learning regression, and a neural network, when training a classifier.
- a single classifier may be trained for use with all services, a classifier may be trained for each service, or a classifier may be trained for each user.
- the OSO-IP service may use a decision tree for classification.
- a decision tree classifier is used to classify data by applying rules of the tree to the data until a leaf node is reached. The data is then assigned the classification of the leaf node.
- a decision tree classifier is typically represented by rules that divide data into a series of binary hierarchical groupings or nodes.
- Each node has an associated rule that divides the data into two child groups or child nodes.
- a decision tree is constructed by recursively partitioning training data. At each node in the decision tree, the prediction system selects a partition that tends to maximize some metric. A metric that is commonly used is based on information gain. Decision tree classifiers and appropriate metrics are described in Quinlan, J. R., “Programs for Machine Learning,” Morgan Kaufmann Publishers, 1993, which is hereby incorporated by reference.
- An implementation of the OSO-IP service may employ any combination of elements of the various embodiments.
- the processing described below may be performed by a computing device with a processor that executes computer-executable instructions stored on a computer-readable storage medium that implements the OSO-IP service.
- a method performed by a computing system of an identity provider service is provided.
- The receives a first sign out notification that a user has requested to sign out of a first account associated with a service.
- a first security token is associated with the first account and generated when the user provided first credentials for the first account.
- the first account is designated as signed in.
- the method requests the user to indicate whether the user wants to sign in to a second account associated with the service.
- the method receives receiving from the user second credentials for the second account, generates a second security token for the second account, and after verifying the second credentials, sends the second security token to the service so that the service can sign the user in to the second account.
- the method designates the first account as soft signed out and the second account as signed in.
- the method further receives a second sign out notification that the user has requested to sign out of the second account.
- the method sends the first security token to the service so that the service can sign the user back in to the first account without the user re-providing the first credentials.
- the method designates the first account as signed in and the second account as soft signed out.
- the method further a second sign out notification that the user has requested to sign out of the second account.
- the method After receiving the second sign out notification, the method requests the user to indicate whether the user wants to switch to the first account W the user indicates to switch to the first account, sends the first security token to the service so that the service can sign the user back in to the first account without the user re-providing the first credentials and designates the first account as signed in and the second account as soft signed out.
- the requesting after receiving the second sign out notification further includes requesting the user to indicate whether to sign out of the second account and when the user indicates to sign out of the second account, the method further designates second account as signed out.
- the method further receives a second sign out notification that the user has requested to sign out of the second account.
- the method After receiving the second sign out notification, the method requests the user to indicate whether the user wants to sign out of the first account and the second account.
- the method sets the state of the first account and the second account to signed out so that the user will need to re-provide the first credentials to sign in to the first account and re-provide the second credentials to sign in to the second account.
- the requesting further includes requesting the user to indicate whether the user wants to sign out of the first account and, when the user indicates to sign out of the first account, designating the first account as signed out; and when the user does not indicate to sign out of the first account, designating the first account as soft signed out.
- the method further receives a second sign out notification that the user has requested to sign out of the second account.
- the method designates the first account as signed in and the second account as signed out to require the user to re-provide the second credentials when signing in to the second account and sends the first security token to the service so that the service can sign the user back in to the first account without the user re-providing the first credentials.
- the method receives a second sign out notification that the user has requested to sign out of the second account. After receiving the second sign out notification, the method requests the user to select one of a plurality of actions with respect to the first account or the second account.
- one of the plurality of actions is to sign in to the first account and stay signed in to the second account. In some embodiments, one of the plurality of actions is to sign in to the first account and sign out of the second account. In some embodiments, one of the plurality of actions is to sign out of the first account and the second account. In some embodiments, one of the plurality of actions is to sign in to a third account. In some embodiments, one of the plurality of actions is designated as a default action. In some embodiments, the plurality of actions are selected based on a machine learning algorithm applied to a log of actions selected by one or more users and features associated with each selection.
- a computing system for providing identity services comprises one or more computer-readable storage media storing computer-executable instructions and one or more processors for executing the computer-executable instructions stored in the one or more computer-readable storage media.
- the instructions when executed, control the computing system to designate a first account of a service as signed in based on first credentials provided by a user and provide a first security token for the first account to the service,
- the instructions further control the computing system to, upon receiving a first sign out notification, determine whether the user wants to switch to a second account with the service
- the instructions further control the computing system to, upon determining that the user wants to switch to the second account, designate the second account as signed in based on second credentials provided by the user, provide a second security token for the second account to the service, and designate the first account as soft signed out so that the user can switch to the first account without re-providing the first credentials.
- the computer-executable instructions when executed, further control the computing system to, upon receiving a second sign out notification, upon determining that the user wants to switch to the first account, designate the first account as signed in, provide the first security token to the service, and designate the second account as being signed out or soft signed out based on determining whether to require the user to re-provide the second credentials when signing in to the second account.
- a method performed by a computing system designates designating a first account of a service as signed in based on first credentials provided by a user.
- the method provides a first security token for the first account to the service.
- the method determines whether the user wants to switch to a second account of the service.
- the method designates the second account as signed in based on second credentials provided by the user, provides a second security token for the second account to the service, and designates the first account as soft signed out so that the user can switch to the first account without re-providing the first credentials.
- the service does not support being signed in to multiple accounts simultaneously from a single device.
- a method performed by a computing system accesses a log of entries collected when an identity provider service provides to a user currently signed in to a service with a first account an intent request. Each entry specifies an action taken when signing out of an account and specifies the user and the service.
- the method generates training data for a classifier that includes feature vectors with labels. The generating includes, for each entry, extracting features associated with the user and the service specified by the entry to form a feature vector and labeling the feature vector with the action specified by the entry.
- the method trains a classifier using the training data to classify likely intended actions based on features associated with a user and a service.
- the trained classifier is adapted to be used by an identity service provider to determine a likely intended action of a user who has signed out of one account of a service and signed in to another account of the service upon receiving a notification that the user has signed out of the other account of the service.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Social Psychology (AREA)
- Accounting & Taxation (AREA)
- Business, Economics & Management (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
Claims (19)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/479,197 US10862681B2 (en) | 2017-04-04 | 2017-04-04 | Optimized sign out for single account services |
PCT/US2018/024696 WO2018187102A1 (en) | 2017-04-04 | 2018-03-28 | Optimized sign out for single account services |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/479,197 US10862681B2 (en) | 2017-04-04 | 2017-04-04 | Optimized sign out for single account services |
Publications (2)
Publication Number | Publication Date |
---|---|
US20180287794A1 US20180287794A1 (en) | 2018-10-04 |
US10862681B2 true US10862681B2 (en) | 2020-12-08 |
Family
ID=61953015
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/479,197 Active 2037-07-10 US10862681B2 (en) | 2017-04-04 | 2017-04-04 | Optimized sign out for single account services |
Country Status (2)
Country | Link |
---|---|
US (1) | US10862681B2 (en) |
WO (1) | WO2018187102A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11144620B2 (en) * | 2018-06-26 | 2021-10-12 | Counseling and Development, Inc. | Systems and methods for establishing connections in a network following secure verification of interested parties |
WO2021080009A1 (en) * | 2019-10-25 | 2021-04-29 | パナソニックIpマネジメント株式会社 | Power transmission device, power reception device, and wireless power transmission system |
CN111953708B (en) * | 2020-08-24 | 2022-08-26 | 北京金山云网络技术有限公司 | Cross-account login method and device based on cloud platform and server |
CN112491931B (en) * | 2020-12-17 | 2023-04-07 | 武汉卓尔信息科技有限公司 | JWT (just noticeable WT) -based current limiting method and device for user authentication |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080134295A1 (en) * | 2006-11-30 | 2008-06-05 | Microsoft Corporation | Authenticating Linked Accounts |
US20090007250A1 (en) * | 2007-06-27 | 2009-01-01 | Microsoft Corporation | Client authentication distributor |
US20100179916A1 (en) * | 2009-01-15 | 2010-07-15 | Johns Tammy | Career management system |
US20140173693A1 (en) * | 2012-12-14 | 2014-06-19 | Microsoft Corporation | Cookie Optimization |
US20140358828A1 (en) * | 2013-05-29 | 2014-12-04 | Purepredictive, Inc. | Machine learning generated action plan |
US20160366126A1 (en) * | 2015-06-15 | 2016-12-15 | Google Inc. | Screen-analysis based device security |
US20170048236A1 (en) | 2015-08-12 | 2017-02-16 | Samsung Electronics Co., Ltd. | Electronic device and method for commonly using the same |
-
2017
- 2017-04-04 US US15/479,197 patent/US10862681B2/en active Active
-
2018
- 2018-03-28 WO PCT/US2018/024696 patent/WO2018187102A1/en active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080134295A1 (en) * | 2006-11-30 | 2008-06-05 | Microsoft Corporation | Authenticating Linked Accounts |
US20090007250A1 (en) * | 2007-06-27 | 2009-01-01 | Microsoft Corporation | Client authentication distributor |
US20100179916A1 (en) * | 2009-01-15 | 2010-07-15 | Johns Tammy | Career management system |
US20140173693A1 (en) * | 2012-12-14 | 2014-06-19 | Microsoft Corporation | Cookie Optimization |
US20140358828A1 (en) * | 2013-05-29 | 2014-12-04 | Purepredictive, Inc. | Machine learning generated action plan |
US20160366126A1 (en) * | 2015-06-15 | 2016-12-15 | Google Inc. | Screen-analysis based device security |
US20170048236A1 (en) | 2015-08-12 | 2017-02-16 | Samsung Electronics Co., Ltd. | Electronic device and method for commonly using the same |
Non-Patent Citations (1)
Title |
---|
"International Search Report and Written Opinion Issued in PCT Application No. PCT/US2018/024696", dated May 29, 2018, 11 Pages. |
Also Published As
Publication number | Publication date |
---|---|
WO2018187102A1 (en) | 2018-10-11 |
US20180287794A1 (en) | 2018-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10862681B2 (en) | Optimized sign out for single account services | |
KR102504077B1 (en) | Image based captcha challenges | |
US11188720B2 (en) | Computing system including virtual agent bot providing semantic topic model-based response | |
US20180032599A1 (en) | Grouped categorization of internet content | |
US9219710B2 (en) | Seamless authentication with proxy servers | |
US11811780B2 (en) | Behavior-based authentication | |
US9270666B2 (en) | Verification of user communication addresses | |
US20160070626A1 (en) | Assessing quality of service provided by applications based on hosting system support | |
US12095771B2 (en) | Split input and output remote access | |
US20190007412A1 (en) | Customized device identification | |
US11036816B2 (en) | Selective collaboration of users within a forum based on prior activity of the users within one or more forums | |
US11139975B2 (en) | Authentication in non-secure communication channels via secure out-of-bands channels | |
CN112181599B (en) | Model training method, device and storage medium | |
US11303672B2 (en) | Detecting replay attacks using action windows | |
US10652341B2 (en) | Restful interface system for an application | |
US10924499B2 (en) | Detection of genuine social media profiles | |
US11736336B2 (en) | Real-time monitoring of machine learning models in service orchestration plane | |
CN116346409A (en) | Network security defense method, device, equipment and storage medium | |
US10728236B1 (en) | Augmented reality data exchange | |
US11171904B1 (en) | Message authentication using generative adversarial networks | |
KR20230118380A (en) | Group signaure based federated learning mehod and system, and recording medium for performing the same | |
US12072969B2 (en) | Personalized password prompting system | |
US20240411861A1 (en) | Advanced deterrence for bots in an interactive communication environment | |
US12093334B2 (en) | System and method of a cloud server for providing content to a user | |
US20240411860A1 (en) | Dynamic creation of temporary isolated environment in an interactive communication environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WALTER, JASON;REEL/FRAME:043650/0380 Effective date: 20170913 |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FORREST, JOHN H;GORDON, ARIEL;REEL/FRAME:043726/0776 Effective date: 20170404 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |