JP6459785B2 - Information processing system - Google Patents

Information processing system Download PDF

Info

Publication number
JP6459785B2
JP6459785B2 JP2015118107A JP2015118107A JP6459785B2 JP 6459785 B2 JP6459785 B2 JP 6459785B2 JP 2015118107 A JP2015118107 A JP 2015118107A JP 2015118107 A JP2015118107 A JP 2015118107A JP 6459785 B2 JP6459785 B2 JP 6459785B2
Authority
JP
Japan
Prior art keywords
token
storage
intra
relay server
plug
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
Application number
JP2015118107A
Other languages
Japanese (ja)
Other versions
JP2017004286A (en
Inventor
淳也 加藤
淳也 加藤
Original Assignee
富士ゼロックス株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 富士ゼロックス株式会社 filed Critical 富士ゼロックス株式会社
Priority to JP2015118107A priority Critical patent/JP6459785B2/en
Publication of JP2017004286A publication Critical patent/JP2017004286A/en
Application granted granted Critical
Publication of JP6459785B2 publication Critical patent/JP6459785B2/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Images

Description

  The present invention relates to an information processing system.

  Technologies that enable access from the Internet to an intranet have been proposed.

  Patent Document 1 discloses a first information processing apparatus connected to the Internet, a first management server that manages access to the intranet from the first information processing apparatus, and a second information processing apparatus connected to the intranet. And a second management server for managing access to the Internet from the second information processing apparatus, and performing bidirectional communication between the first management server and the second management server. A global account management server that performs login management on the Internet and an ACL server that performs access management on an intranet communicate with each other.

JP 2012-238150 A

  By simply deciding whether or not each service can be used by ACL (Access Control List), the linkage between multiple services is not taken into consideration. In particular, there is a connection between the public cloud storage service on the Internet and the storage service on the intranet. Cooperation is not planned.

  Further, if the global account and the account in the intranet are directly associated and managed, there is a disadvantage that the association itself becomes invalid when the global account is changed.

  An object of the present invention is to provide an information processing system that can use both the cloud on the Internet and the storage in the intranet, and that does not affect the use even when the account is changed.

  The invention according to claim 1 stores, in the intranet, a storage, a proxy that issues a token associated with authentication information for permitting use of the storage, and the token associated with the authentication information. A first database, a relay server that accesses the cloud on the Internet from the intranet, a second database that stores the token in association with an account, and a processing unit that accesses the proxy using the token Information processing system.

  According to a second aspect of the present invention, when the use of the storage is requested from a user terminal, the relay server reads the token from the second database and transmits the token to the proxy. The information processing system according to claim 1, wherein the storage is accessed using the authentication information associated with the token from one database.

  According to a third aspect of the present invention, the proxy issues an update token when the token is not usable and stores it in the first database in association with the authentication information, and the relay server stores the update token. Storing in the second database in association with the account, and automatically starting a request from the user terminal that was suspended when the token is unavailable and sending the renewal token to the proxy; An information processing system according to claim 2.

  According to the first aspect of the present invention, both the cloud on the Internet and the storage in the intranet can be used. In addition, changes to the account will not affect the use of storage in the intranet.

  According to the second aspect of the present invention, the authentication information for using the storage in the intranet is held in the intranet, and security is ensured.

  According to the third aspect of the present invention, more efficient processing is possible compared to the case where a request is transmitted again from the user terminal.

It is a system configuration figure of an embodiment. It is a processing flowchart (the 1) of an embodiment. It is a processing flowchart (the 2) of an embodiment. It is a processing flowchart (the 3) of an embodiment. It is a processing flowchart (the 4) of an embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

<System configuration>
FIG. 1 is a system configuration diagram of an information processing system in the present embodiment. The system includes an intranet 10 and a relay server 12. The relay server 12 accesses a plurality of clouds A14 and cloud B16 on the Internet. The relay server 12 generally relays data by transferring data received from a plurality of tenants to a plurality of clouds. Each of the plurality of clouds uses a different API (Application Programming Interface) for each cloud, and when a plurality of tenants of the plurality of intranets 10 use the services of each cloud, the API of each cloud must be known in advance. Don't be. The relay server 12 provides each tenant with only a unified API by concealing the API of each cloud so that each tenant can use a plurality of cloud services without knowing a different API for each cloud. .

<Intranet>
The intranet 10 in this embodiment includes an account mapping database (DB) 101, an intranet (hereinafter referred to as “intra” as appropriate) storage 102, a client (application) 103, and a storage proxy 104.

  The account mapping DB 101 functions as a first database, and is a database that manages credential information for accessing the intra storage 102, that is, authentication information such as an ID and password, and a token in association with each other.

  The intra storage 102 is a storage provided in the intranet 10 and basically permits access from within the intranet 10, but in this embodiment, permits access via the relay server 12.

  The client 103 is a client in the intranet 10 and is an application that operates on a user terminal. The user starts an application on the user terminal and accesses the relay server 12.

  The storage proxy 104 is a proxy server for accessing the intra storage 102. The storage proxy 104 performs mutual communication with the storage proxy plug-in of the relay server 12 and accesses the intra storage 102 in response to a request from the storage proxy plug-in.

<Relay server>
On the other hand, the relay server 12 in this embodiment includes a storage proxy plug-in 121, a plug-in database (DB) 122, an account database (DB) 123, a token database (DB) 124, a plug-in A 125, and a plug-in B 126.

  The storage proxy plug-in 121 functions as a processing unit, and is a plug-in for performing mutual communication with the storage proxy 104 in order to access the intra storage 102. A plug-in is a program added to expand functions.

  The plug-in DB 122 is a database that manages plug-ins for accessing a plurality of clouds and the storage proxy 104. The plug-in 121 for storage proxy, plug-in A125, plug-in B126, and other plug-ins are registered in this database.

  The account database (DB) 123 is a database that manages accounts of a plurality of tenants (users).

  The token database (DB) 124 functions as a second database, and is a database that manages tenant accounts and tokens issued from each cloud in association with each other. The token includes a token issued from the cloud A14, a token issued from the cloud B16, and a token issued from the storage proxy 104.

  The plug-in A125 is a plug-in for accessing the cloud A14 of the plurality of clouds.

  The plug-in B126 is a plug-in for accessing the cloud B16 of the plurality of clouds.

  The relay server 12 includes a CPU, a memory, a storage device, and an input / output interface as a hardware configuration. The CPU implements various processes by reading and executing the processing program stored in the program memory. The main processing is to relay access to the cloud A14 and cloud B16 on the Internet and access to the intra storage 102 in the intranet 10 in response to a request from a user terminal in the intranet. The storage proxy plug-in 121 as the processing means is realized by the CPU reading and executing the storage plug-in program. Although the plug-in DB 122, the account DB 123, and the token DB 124 are realized by a storage device, they are not necessarily the same storage device, and may be realized separately by a plurality of storage devices.

  The storage proxy 104 in the intranet 10 includes a CPU, a memory, a storage device, and an input / output interface as a hardware configuration. The CPU implements various processes by reading and executing the processing program stored in the program memory. The main processing is to issue a token in response to a request from the relay server 12, update the token, and perform user authentication to the intra storage 102 using the token. The account mapping DB 101 and the intra storage 102 are realized by the same or different storage devices.

<Basic processing>
The basic processing of the system in this embodiment is as follows. The administrator of the intranet 10 accesses the storage proxy 104 from within the intranet 10 and registers the storage proxy 104 in the relay server 12.

  The relay server 12 registers information necessary for accessing the storage proxy 104 in the plug-in DB 122 in association with the intranet (tenant) 10. As a result of this registration, when a user belonging to the intranet 10 logs in to the relay server 12, a list of available plug-ins including the registered plug-ins can be acquired, and both the cloud A 14 and the cloud B 16 and the intra intra storage 102 are stored. Can be used.

  In the present embodiment, the storage in the cloud A14, the storage in the cloud B16, and the intra-intra storage 102 can be equivalently used via the relay server 12, and the intra-internal storage 102 is registered in the same manner as when a document is registered in the storage in the cloud A14. The document can be registered in the intra storage 102 in the same manner as the document is acquired from the storage of the cloud A14. As a matter of course, a user belonging to the intranet 10 can directly access the intra storage 102, but in this embodiment, the intra storage 102 is also connected to the intra storage 102 via the relay server 12 for using the cloud service on the Internet. Accessible.

  Further, the storage proxy 104 issues a token to be used for accessing the intra storage 102 from the relay server 12 for each user, and associates the authentication information for accessing the intra storage 102 with the token to account mapping DB 101. Register with. A token is a special signal or data that means a transmission right that circulates on the network. The user who has acquired the token transmits this token to the relay server 12, and the relay server 12 associates the account with the token and registers them in the token DB 124 in the same manner as in the other cloud A14 and cloud B16. When the user uses the intra storage 102, the relay server 12 acquires the token associated with the intra storage 102 to be accessed from the token DB 124, and the storage proxy plug-in 121 acquires the token. The token is sent to the storage proxy 104. The storage proxy 104 acquires authentication information that matches the received token from the account mapping DB 101, and accesses the intra-storage 102 using the acquired authentication information.

  In the present embodiment, the user also uses the storage proxy plug-in 121 for accessing the intra storage 102 in addition to the plug-in A 125 and plug-in B 126 for accessing the cloud A 14 and the cloud B 16 that are public clouds. Therefore, it is possible to use a storage service on the Internet and an intra-storage service.

  Further, in the present embodiment, the credential information (authentication information) is held in the intranet 10 and is not held in the relay server 12, so that security is also ensured.

  Further, the tenant account of the relay server 12 and the token are associated and registered in the token DB 124, and the user authentication information (user account) and the token are associated and registered in the account mapping DB 101, and the tenant of the relay server 12 is registered. Since the account in the intra and the account in the intra are indirectly associated using a token, even if the tenant account of the relay server 12 is changed, the account is not affected. That is, even if the tenant's account is changed, it is possible to acquire the correct authentication information and access the access destination by specifying the access destination token of the tenant. As long as the token is valid, this embodiment can be said to be a system that can access the intra storage 102 in the same manner as the cloud A14 and the cloud B16 on the Internet regardless of the tenant's account.

  In other words, when an abnormality occurs in the token, for example, when the expiration date is set for the token and the expiration date has expired, or the authentication information (ID and password) of the intra storage 102 itself has been changed. In this case, it means that access to the intra storage 102 is blocked. In this case, in order to use the intra storage 102, it is necessary to reissue or renew the token.

<Detailed processing>
Next, the processing of the system in the present embodiment will be described in order, divided into storage proxy 104 registration, account mapping, use of intra storage 102 (normal), and use of intra storage 102 (abnormal).

<Register storage proxy>
FIG. 2 is a flowchart of processing for registering the storage proxy 104 in the relay server 12. Intra-user, intra-administrator, relay server 12, storage proxy plug-in (SP plug-in) 121, and storage proxy (SP) 104 It is processing of.

  First, the intra administrator registers a tenant with the relay server 12 using a terminal in the intra, and creates a user in the tenant.

  Next, the intra administrator accesses the SP 104 from within the intra using a terminal in the intra, and performs an operation of registering the SP 104 in the relay server 12. At this time, the SP 104 redirects (transfers) to the relay server 12, and the relay server 12 confirms that the intra administrator logs in to the relay server 12 to be a tenant administrator of the relay server 12.

  The intra administrator designates information necessary for accessing the SP 104 after logging in to the relay server 12, and the relay server 12 confirms that the SP 104 can access the SP 104 with the information, and then designates the designated access information with the tenant ID. And registered in the plug-in DB 122. With the above processing, the SP plug-in 121 is registered in the relay server 12, and the SP server can be accessed from the relay server 12 using the SP plug-in 121.

  Next, the user in the intra, that is, the user created in the tenant by the intra administrator logs in to the relay server 12 using the terminal in the intra. The relay server 12 returns a list of available plug-ins registered in the plug-in DB 122 to the user. This plug-in list includes an SP plug-in 121 for using the intra storage 102 in addition to the plug-in A 125 for using the cloud A 14 and the plug-in B 126 for using the cloud B 16.

  As described above, the registration of the SP 104 with the relay server 12 is an intra administrator, that is, a tenant administrator, and is executed from within the tenant's intra, so that the SP 104 is illegally registered and used by an unauthorized tenant. There is no.

<Account mapping>
FIG. 3 is a flowchart of the account mapping process, which is a process of the intra-user, the relay server 12, the SP plug-in 121, the SP 104, and the intra-storage 102. This process is a process after the registration process of SP 104 shown in FIG. 2 is completed.

  First, when an intra user logs in to the relay server 12 using a terminal in the intra and makes a cloud service list acquisition request, the relay server 12 acquires a plug-in list usable by the tenant from the plug-in DB 122. And reply to the intra-user.

  Next, the intra user selects the SP plug-in 121 from the plug-in list and makes a token acquisition request to the relay server 12 to use the intra storage 102.

  The SP plug-in 121 of the relay server 12 redirects (transfers) the token acquisition request to the SP 104.

  Next, the intra-user accesses the SP 104 and performs authentication for accessing the intra-storage 102. In other words, the intra user requests the SP 104 for permission to use, and the SP 104 authenticates the intra storage 102. Since the authentication information is transmitted from the intra-user to the intra-storage 102 via the SP 104, the authentication information does not pass through the relay server 12. However, intra-users cannot access the SP 104 unless they use the SP plug-in 121, and cannot perform account mapping unless they can access the SP 104.

  If the authentication is successful, the SP 104 issues a token that can use the intra storage 102, and registers the issued token and authentication information in association with each other in the account mapping DB 101. The issued token is returned to the intra-user. The token may have an expiration date, and processing when the token expires will be described later.

  The intra-user who acquired the token transmits the token to the relay server 12, and the relay server 12 associates the tenant (user) account with the token and registers them in the token DB 124 in the same manner as other cloud services. The token is given an attribute that makes the intra storage 102 available. If the access destination included in the request from the user terminal is the intra storage 102, the relay server 12 can read the corresponding token from the token DB 124.

  Through the above processing, the token that can use the intra storage 102 associated with the account is registered in the token DB 124 of the relay server 12, and the token associated with the authentication information is registered in the account mapping DB 101 of the intranet 10. . Therefore, the tenant account of the relay server 12 and the authentication information (account) of the user in the intranet 10 are indirectly associated via a token that can use the intra storage 102 issued in the SP 104.

  Here, focusing on the tenant account, the SP plug-in 121 is registered in the plug-in DB 122 of the relay server 12 in association with the tenant account, and the intra-intra site is associated with the tenant account in the token DB 124 of the relay server 12. A token that can use the storage 102 is registered. When the tenant account is changed, the plug-in DB account and the token DB account are changed according to the change, so that the user can correctly use the SP plug-in 121 and the token even in the account after the change.

<Use of intra-storage>
FIG. 4 is a processing flowchart when the intra storage 102 is used (for example, acquisition of a document stored in the intra storage 102), and the user (may be inside or outside the intra). , Processing of the relay server 12, the SP plug-in 121, the SP 104, and the intra storage 102.

  First, when a user logs in to the relay server 12 using a terminal and makes a cloud service list acquisition request, the relay server 12 acquires a plug-in list that can be used by the tenant from the plug-in DB 122, and Send back.

  The user selects the SP plug-in 121 from the plug-in list and makes a document acquisition request.

  The relay server 12 reads an access destination, that is, a token that can use the intra storage 102 from the token DB 124, and the SP plug-in 121 transmits this token to the SP 104 when accessing the SP 104.

  The SP 104 reads authentication information that matches the received token from the account mapping DB 101 and logs in to the intra storage 102 using the read authentication information. If the login is successful, the process according to the request from the user, that is, the document acquisition request is executed, and the requested document is transmitted to the user.

<Token update process>
FIG. 5 is a processing flowchart in the case of using intra storage (for example, registering a document in intra storage 102), in the event of an abnormality such as a token expired or a password has been changed. It is processing. In this case, it is necessary to update the token to make the intra storage 102 available.

  First, the intra user makes a document registration request to the relay server 12.

  The relay server 12 reads the token corresponding to the access destination, that is, the intra storage 102, from the token DB 124, and the SP plug-in 121 passes the token to the SP 104.

  The SP 104 reads the authentication information that matches the token from the account mapping DB 101. At this time, if there is no authentication information that matches the token because the token has expired or the password has been changed, the SP 104 notifies the SP. Return to plug-in 121. The SP plug-in 121, that is, the relay server 12, suspends document registration until the token is updated, and returns a token update request to the intra-user.

  The intra-user receives the token update request from the relay server 12, accesses the SP 104, and makes a token update request. When the user is outside the intra, the SP 104 cannot be accessed, so the token cannot be updated until the user returns to the intra.

  Upon receiving an update request from an intra-user, the SP 104 updates the intra-storage 102 by reissuing a usable token, and re-registers the updated token and authentication information in the account mapping DB 101 in association with each other. A new expiration date is set for the updated token, and new authentication information including the changed password is associated with the updated token.

  When the SP 104 updates the token, the SP 104 returns a message to that effect to the relay server 12 and the intra-user, and the intra-user requests the relay server 12 to update the token. The relay server 12 associates the token updated at SP 104 with the account and re-registers it in the token DB 124. The relay server 12 automatically re-registers the updated token in the token DB 124 and then automatically resumes the pending document registration request, and the SP plug-in 121 passes the updated token to the SP 104 to request document registration. To do. The SP 104 reads authentication information suitable for the received token from the account mapping DB 101, and accesses the intra storage 102 using the read authentication information to perform document registration.

  As described above, even if it is necessary to update the token or change the password in the intra, the request for document registration to the relay server 12 is suspended, and the suspended request is automatically resumed upon completion of the token update. Thus, efficient processing is possible.

  10 intranet (intra), 12 relay server, 14 cloud A, 16 cloud B, 101 account mapping database (DB), 102 intra storage, 103 client (application), 104 storage proxy (SP), 121 plug-in for storage proxy (SP plug-in), 122 plug-in database (DB), 123 account database (DB), 124 token database (DB), 125 plug-in A, 126 plug-in B.

Claims (3)

  1. Within the intranet,
    Storage,
    A proxy that issues a token associated with authentication information for permitting use of the storage;
    A first database that stores the token associated with the authentication information;
    Is provided,
    To the relay server that accesses the cloud on the Internet from the intranet,
    A second database for storing the token in association with an account;
    An information processing system provided with processing means for accessing the proxy using the token.
  2. The relay server reads the token from the second database and sends it to the proxy when the user terminal requests use of the storage,
    The proxy accesses the storage using the authentication information associated with the token from the first database;
    The information processing system according to claim 1.
  3. The proxy issues an update token when the token is unavailable and stores it in the first database in association with the authentication information;
    The relay server stores the update token in the second database in association with the account, and automatically initiates a request from the user terminal that has been suspended when the token is not available. Send a refresh token to the proxy;
    The information processing system according to claim 2.
JP2015118107A 2015-06-11 2015-06-11 Information processing system Active JP6459785B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015118107A JP6459785B2 (en) 2015-06-11 2015-06-11 Information processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015118107A JP6459785B2 (en) 2015-06-11 2015-06-11 Information processing system

Publications (2)

Publication Number Publication Date
JP2017004286A JP2017004286A (en) 2017-01-05
JP6459785B2 true JP6459785B2 (en) 2019-01-30

Family

ID=57754778

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015118107A Active JP6459785B2 (en) 2015-06-11 2015-06-11 Information processing system

Country Status (1)

Country Link
JP (1) JP6459785B2 (en)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7219154B2 (en) * 2002-12-31 2007-05-15 International Business Machines Corporation Method and system for consolidated sign-off in a heterogeneous federated environment
JP2012238150A (en) * 2011-05-11 2012-12-06 Ricoh Co Ltd Information processing system and information processing method
JP5962261B2 (en) * 2012-07-02 2016-08-03 富士ゼロックス株式会社 Relay device
US9356918B2 (en) * 2013-03-13 2016-05-31 Google Inc. Identification delegation for devices

Also Published As

Publication number Publication date
JP2017004286A (en) 2017-01-05

Similar Documents

Publication Publication Date Title
JP6207696B2 (en) Safe mobile framework
US10182052B2 (en) Proxy authentication
CN105659558B (en) Computer implemented method, authorization server and computer-readable memory
US20170329978A1 (en) Device and methods for management and access of distributed data sources
US10303871B2 (en) System and method for controlling state tokens
US20150222614A1 (en) Authentication server auditing of clients using cache provisioning
US9792742B2 (en) Decentralized virtual trustless ledger for access control
US8955041B2 (en) Authentication collaboration system, ID provider device, and program
JP6006533B2 (en) Authorization server and client device, server linkage system, and token management method
JP6066647B2 (en) Device apparatus, control method thereof, and program thereof
O’Malley et al. Hadoop security design
CN102638454B (en) Plug-in type SSO (single signon) integration method oriented to HTTP (hypertext transfer protocol) identity authentication protocol
JP6198477B2 (en) Authority transfer system, authorization server system, control method, and program
CN102104592B (en) Session migration between network policy servers
US7330971B1 (en) Delegated administration of namespace management
EP2733909B1 (en) Terminal control method and device, and terminal
ES2440826T3 (en) System and procedure for delegation of privileges and control
JP3937475B2 (en) Access control system and method
CN104054321B (en) For the safety management of cloud service
EP2819052B1 (en) Method and server for processing a request for a terminal to access a computer resource
JP4579546B2 (en) Method and apparatus for handling user identifier in single sign-on service
KR20130007797A (en) Method and system for open authentication
EP2940968A1 (en) Network infrastructure management
JP2013532394A (en) System and method for remote maintenance in an electronic network having multiple clients
US8572268B2 (en) Managing secure sessions

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180228

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20181114

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181217

R150 Certificate of patent or registration of utility model

Ref document number: 6459785

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150