JP2018018157A - Information processing equipment for service provider side, information processing method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize a consistent IP address restriction, as well as to prevent unnecessary processing.SOLUTION: Information processing equipment includes: receiving means configured to receive an authentication message from a client device; and control means configured to omit restriction processing of the IP address if it is determined as single sign-on according to the authentication message, and to execute restriction processing of the IP address if it is determined as not single sign-on according to the authentication message.SELECTED DRAWING: Figure 6

Description

  The present invention relates to an information processing apparatus, an information processing method, and a program on a service provider side.

Currently, the form of using cloud services by API access using REST from a web browser is becoming the de facto standard. This is influenced by trends such as the spread of mobile and the appearance of browser OS.
In the case of cloud services for business use, there is a request that internal access is possible but access from outside the company is prohibited. In this case, access prohibition means using an IP address can be considered. Conventionally, it has been proposed to establish single sign-on (SSO) for network access and to restrict access in the network (Patent Document 1). The access restriction method based on the IP address at the time of single sign-on enables a consistent access restriction behavior when both the ID provider (IdP) and the service provider (SP) restrict access by the IP address.

JP 2008-219266 A

It is assumed that the IP address is restricted on the service provider (SP) side when the single sign-on (SSO) setting is performed and the IP address restriction on the ID provider (IdP) side is applied. In this case, it is necessary to check the IP address restriction twice during SSO.
An object of the present invention is to realize consistent IP address restriction and prevent wasteful processing.

  The information processing device on the service provider side of the present invention omits the IP address restriction process when it is determined that the single sign-on is based on the receiving means that receives the authentication message from the client device and the authentication message, And a control unit that executes IP address restriction processing when it is determined that the single sign-on is not performed based on the authentication message.

  According to the present invention, it is possible to realize consistent IP address restriction and prevent wasteful processing.

It is a figure which shows an example of the system configuration | structure of an SSO system. It is a figure which shows an example of the hardware constitutions of client PC. It is a figure which shows an example of a software structure. It is a sequence diagram which shows an example of the information processing in the case of SSO. It is a flowchart which shows an example of an IdP side login process. 4 is a flowchart illustrating an example of SP-side login processing according to the first embodiment. It is a login sequence diagram. 10 is a flowchart illustrating an example of SP-side login processing according to the second embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
The single sign-on system of the embodiment described below performs single sign-on (hereinafter referred to as SSO) setting according to the SAML 2.0 specification, and performs SSO. At this time, an ID provider (hereinafter referred to as IdP) can determine an access source IP address and perform access restriction based on the IP address. Similarly, the service provider (hereinafter referred to as SP) of the present embodiment can perform access restriction based on access source IP address determination similar to IdP.
However, if the IP address restriction settings are different on the IdP side and the SP side, that is, if the user performing the SSO settings places different IP address restrictions on the IdP side and the SP side, the user May be confused. For example, when the IP address is restricted by the SP and the IP address is not restricted by the IdP, the IP address is restricted by the SP during the SSO process even though the IdP authentication is successful. Conversely, if IP addresses are restricted by IdP but not by SP, the following problems may occur. In other words, even if the service use when logging in directly to the SP is not restricted, if you try to use the SP after logging in (SSO) with a Web browser or the like, the IP address restriction will be imposed at the time of IdP authentication. is there.
In this way, in an SSO system in which IP address restrictions can be made individually at the IdP and SP during SSO, if IP address restrictions differ between the IdP side and the SP side, the IP address restriction is viewed from the user's perspective. May not show consistent behavior.
The SSO system of the embodiment described below behaves consistently with respect to IP address restriction at the time of SSO when viewed from the user when IP address restriction is performed individually for IdP and SP.

FIG. 1 is a diagram illustrating an example of a system configuration of an SSO system.
The WAN 100 is a Wide Area Network, and in this specification, a World Wide Web (WWW) system is constructed. LANs 101, 102, and 103 are local area networks that connect each component.
The client PC 200 is a client PC operated by the user. The ID provider 300 is an ID provider that performs SSO user authentication processing. Furthermore, the service provider 400 is a service provider who provides a service to a user who has logged in with SSO or the like. The service provider 400 performs a form creation service and a print data generation service on the cloud, for example. The ID provider 300 is an example of an information processing apparatus on the ID provider side. The service provider 400 is an example of an information processing apparatus on the service provider side.
The client PC 200, the ID provider 300, and the service provider 400 are connected via the WAN 100, the LAN 101, the LAN 102, and the LAN 103, respectively. The services such as the ID authentication service of the client PC 200 and the ID provider 300 and the form generation and print data generation services of the service provider 400 may be configured on individual LANs or on the same LAN. Also good. Moreover, you may be comprised on the same PC.
The ID provider 300 and the service provider 400 perform a single sign-on operation according to the Security Assession Markup Language 2.0 (SAML 2.0) specification. SAML is an XML specification for exchanging IDs, passwords, and the like on the Internet formulated by the non-profit international consortium OASIS. OASIS is an abbreviation for Organization for the Advancement of Structured Information Standards.
In the present embodiment, both the ID provider 300 and the service provider 400 have a function of restricting access to the server based on an access source IP address at the time of login to each server and single sign-on. The service provider 400 has a direct login function to the service provider 400 in addition to the SSO.

FIG. 2 is a diagram illustrating an example of a hardware configuration of the client PC 200. The hardware configurations of the server computers of the ID provider 300 and the service provider 400 are the same. The hardware configuration shown in FIG. 2 corresponds to the hardware configuration of a general information processing apparatus, and the hardware configuration of a general information processing apparatus can be applied to the client PC 200 and the server computer of this embodiment.
The CPU 201 executes programs such as an OS and applications stored in the program ROM of the ROM 203 or loaded from the hard disk 211 to the RAM 202. Here, the OS is an abbreviation for an operating system running on a computer, and the operating system is hereinafter referred to as an OS. When the CPU 201 executes processing based on the program, the software configuration of the client PC 200 and the processing of the client PC 200 in the sequence diagrams of FIGS. 4 and 7 described later are realized. A keyboard controller (KBC) 205 controls key input from a keyboard (KB) 209 or a pointing device. A CRT controller (CRTC) 206 controls display on a CRT display 208. A disk controller (DKC) 207 controls data access in a hard disk (HD) 211 or a flexible disk (FD) that stores various data. The NC 212 is connected to the network and executes communication control processing with other devices connected to the network.

When the CPU of the ID provider 300 executes processing based on a program stored in the hard disk or the like of the ID provider, the software configuration of the ID provider 300 and the processing of the ID provider 300 in the sequence diagram of FIG. 4 to be described later are realized. Further, the CPU of the ID provider 300 executes the processing based on a program stored in the ID provider hard disk or the like, thereby realizing the processing of the flowchart of FIG.
Further, the software configuration of the service provider 400 is realized by the CPU of the service provider 400 executing processing based on a program stored in the hard disk or the like of the service provider 400. Also, the processing of the service provider 400 in the sequence diagrams of FIGS. 4 and 7 described later is realized by the CPU of the service provider 400 executing the processing based on the program stored in the hard disk or the like of the service provider 400. Further, the processing of the flowcharts of FIGS. 6 and 8 to be described later is realized by the CPU of the service provider 400 executing the processing based on the program stored in the hard disk or the like of the service provider 400.

FIG. 3 is a diagram illustrating an example of software configurations of the client PC 200, the ID provider 300, and the service provider 400.
The OS 210 may generally be a real-time OS or a general-purpose OS such as Linux (registered trademark). The client PC 200 further includes a web browser 220 that is a user agent for using the WWW. The client PC 200 includes a Web API client 230 that uses a Web API server using the HTTP protocol without using the Web browser 220. Furthermore, the client PC 200 includes an application client 240 that is an application that uses a Web API. The application client 240 is an application that uses a Web API service that provides functions of form generation and print data generation provided by the service provider 400, which will be described later, using a Web API.

  The ID provider 300 has the same OS 310 as the client PC 200. Further, the ID provider 300 has a Web API server 320. The Web API server 320 receives an SSO request redirected from a client PC 200 described later. The ID provider 300 includes an authentication module 330 that performs SSO request and user authentication, and further includes a database (DB) module 340 that stores authentication-related information used by the authentication module 330. Further, the ID provider 300 has an SSO management module 350 that accepts login by a user of the ID provider 300 using the Web API server 320, the authentication module 330, and the DB module 340, and performs SSO setting and management.

  The service provider 400 has the same OS 410 as that of the client PC 200. Further, the service provider 400 has a Web API server 420. The Web API server 420 accepts an SSO request and a service request from the client PC 200 described later. The service provider 400 includes an authentication module 430 that performs SSO request and user authentication, and further includes a database (DB) module 440 that stores authentication-related information used by the authentication module 430. Further, the service provider 400 has an SSO management module 450 that accepts login by a user of the service provider 400 using the Web API server 420, the authentication module 430, and the DB module 440, and performs SSO setting and management. Further, the service provider 400 has an application server 460 that is a module for realizing an application function. The application server 460 is, for example, an OAuth authentication library, a form format creation library, a print data conversion application, or the like.

<Embodiment 1>
[The IP address restriction on the SP side is omitted during SSO when there are IP address restrictions on both IdP and SP]
FIG. 4 is a sequence diagram illustrating an example of information processing during SSO. The SSO sequence of this embodiment is basically an SP-initiated SSO sequence in which the authentication sequence starts from access to the SP according to the SAML 2.0 specification. The communication method uses HTTP binding that maps the SAML message to the HTTP protocol. However, in the present embodiment, both the IdP side and the SP side have a function of judging the access source IP address of the access user and rejecting access from other than the access permission IP address registered in advance.
[Construction of trust relationship between IdP and SP in SSO]
Before the SSO sequence of FIG. 4 starts, it is assumed that preparations (establishment of trust relationship) on the IdP side and SP side necessary for conforming to the SAML 2.0 specification are completed. That is, it is assumed that the registration of the IdP trusted by the SP and the registration of the SP trusted by the IdP are performed. More specifically, registration is performed as follows.
[IdP side: registration of trusted SP]
The trusted SP registration on the IdP side means that an IdP user logs in to the IdP and registers trusted SP information (SP metadata) using the SSO management function of the SSO management module 350 of the IdP. The IdP SSO management module 350 holds the SP metadata information and the secret key in the DB module 340 in association with the user.
The main information registered on the IdP side is as follows.
The URL of the endpoint where the SP receives the authentication response message
-IdP private key used for signing an authentication response message for each SSO user In this embodiment, the user who performs SSO uses the SSO management module 350 to send information to the IdP side as metadata as shown in Table 1 below. sign up.

(Table 1: SP metadata registered in IdP)
"
<Md: Entity Descriptor entityID = "https://example.com">
<Md: SPSSODscriptor protocolSupportEnumeration = “urn: oasis: names: tc: SAML: 2.0: protocol”>
<Md: NameIDFormat>
urn: oasis: names: tc: SAML: 1.1: nameid-format: unspecified
</ Md: NameIDFormat>
<Md: AssertionConsumerServiceBinding = “urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST” Location = “https://example.com/endp/samp/acs” 0 ” "/>
</ Md: SPSSODDescriptor>
</ Md: Entity Descriptor>
"

The SP metadata in Table 1 is HTTP-POST (<md: AssertionConsumerServiceBinding = “urn: oasis: names: tc: SAML: 2.0: bindings :) of the AssertionConsumerService that is the URL of the endpoint at which the SP receives the authentication response message. HTTP-POST "Location =" https://example.com/endp/sam/acs "index =" 0 "/>).
The SSO management module 350 verifies the IdP private key used for signing the authentication response message for each SSO user and the signature of the authentication response message described later corresponding to the IdP private key when registering the SP metadata. Generate a public key.
The SSO management module 350 of the IdP holds the SP metadata in Table 1 and the IdP private key used for signing the authentication response message in the DB module 340 in association with the SSO user.
When a user who makes SSO settings on the IdP side registers the SP metadata in Table 1 in the IdP, the SSO management module 350 of the IdP outputs its own IdP metadata for registration as an IdP trusted on the SP side. . A user who sets a trusted IdP on the SP side registers IdP metadata (details will be described later) on the SP side.

[SP side: Registration of trusted IdP]
The trusted IdP registration on the SP side means that the SP user logs in to the SP and registers the trusted IdP information using the SSO management function of the SSO management module 450 of the SP. The SP SSO management module 450 holds the IdP metadata information and the secret key in the DB module 440 in association with the user.
The main information registered in the SP is as follows.
-URL where IdP accepts authentication requests
-IdP public key (for signature verification using the IdP private key included in the authentication response from the IdP)
In this embodiment, a user who performs SSO registers information on the SP side as IdP metadata as shown in Table 2 below.

(Table 2: IdP metadata registered in SP)
"
<Md: EntityDescriptor xmlns: md = "urn: oasis: names: tc: SAML: 2.0: metadata" xmlns: ds = "http://www.w3.org/2000/09/xmlsig#" entityID " https://mashuga-developer-edition.my.salesforce.com “validUntil =” 2025-04-02T05: 46: 23.311Z ”>
<Md: IDPSSODescriptor protocolSupportNumeration = “urn: oasis: names: tc: SAML: 2.0: protocol”>
<Md: KeyDescriptor use = “signing”>
<Ds: KeyInfo>
<Ds: X509Data>
<Ds: X509 Certificate>
MIIEXjCCA0agAwIBAGIOAUJE1fnCAAAAAAGXasyIwDQYJKoZIhvcNAQEFBQAweD
:
2kYLFIM7s3Ss / d + UV7MhgFmTP + LuCjSSUvk2EQdZ86Gx5ALt4 + lkBwBKqCVtu
</ Ds: X509 Certificate>
</ Ds: X509Data>
</ Ds: KeyInfo>
</ Md: KeyDescriptor>
<Md: NameIDFormat>
urn: oasis: names: tc: SAML: 1.1: nameid-format: unspecified
</ Md: NameIDFormat>
<Md: SingleSignOnService Binding = “urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST” Location = “https://example.com/idp/endp/Http>”
<Md: SingleSignOnServiceBinding = “urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect” Location = “https://idp.example.com/idp/endp/rtp/rtp/rtp/rtp/rtp/rtp/rtp/rtp/rtp
</ Md: IDPSSODescriptor>
</ Md: Entity Descriptor>
"

The IdP metadata in Table 2 includes the SingleSignOnService HTTP-POST (<md: SingleSignOnService Binding = “urn: oasis: names: tc: SAML: 2.0: bindings: HTTP: STP: STP: STP: STP”) Location = “https://idp.example.com/idp/endp/HttpPost” />) and HTTP-Redirect (<md: SingleSignOnService Binding = “urn: oasis: names: tc: SAML: 2.0: SAML: b: HTTP-Redirect “Location =” https://idp.example.com/idp/endp / HttpRedirect "/>). In addition, the IdP metadata includes X.X including an IdP public key. 509 format public key certificate (<ds: X509 Certificate>). Note that HTTP-POST indicates an endpoint that receives an authentication request by a POST message of the HTTP protocol. In the case of this embodiment, the authentication request is made with a POST message. HTTP-Redirect indicates an endpoint that receives an authentication request with a GET message of the HTTP protocol. If an authentication request is made with a GET message, the authentication message is added to the URL query parameter.
The SP SSO management module 450 associates the IdP metadata in Table 2 with the SSO user and holds the IdP metadata in the DB module 440.

[IP address restriction settings]
Before the SSO sequence shown in FIG. 4 starts, it is assumed that preparations on the IdP side and SP side necessary for IP address restriction (setting of IP address restriction) are completed. That is, it is assumed that an IdP user has registered an access source IP address that allows a user to connect using the SSO management function of the IdP SSO management module 350. In addition, it is assumed that the SP user has registered the access source IP address that permits the user to connect using the SSO management function of the SP SSO management module 450. More specifically, the setting is performed as follows.

[IdP side: IP address restriction setting]
The IdP side IP address restriction setting means that an IdP user logs in to the IdP, and the IdP SSO management module 350 uses the IdP IP address restriction management function to access the IdP for the managed user. It is to register an IP address. The IP address to be registered may be an individual IP address or an IP address range.
The IdP IP address restriction setting is managed by the following IP address restriction setting table existing in the DB module 340 inside the IdP.
(Table 3: IdP side IP address restriction setting table)
"
User ID: Access-permitted IP address User0001: 192.168 .. *. *
User0001: 172.16.0. * − 172.20.0. *
"
The IdP side IP address restriction setting table in Table 3 shows that when User0001 accesses IdP, the range of 192.168.0.0/16 and 172.16.0.0 to 172.20.0 as the access source IP address. Allow IP address range up to 255.

[SP side: IP address restriction setting]
The setting of the IP address restriction on the SP side means that the SP user logs in to the SP, and the SP's SSO management module 450 uses the SP's IP address restriction management function to access the SP to the management target user. It is to register an IP address. The IP address to be registered may be an individual IP address or an IP address range.
The IP address restriction setting of the SP is managed by the following IP address restriction setting table existing in the DB module 440 inside the SP.
(Table 4: SP side IP address restriction setting table)
"
User ID: Access-permitted IP address User0001: 192.168 .. *. *
User0001: 172.16.0. * − 172.20.0. *
"
The SP-side IP address restriction setting table of Table 4 shows that when User0001 accesses the SP, the access source IP address ranges from 192.168.0.0/16 and 172.16.0.0 to 172.20. IP address range up to 0.255 is allowed.
After the above-described [Building Trust Relationship between IdP and SP in SSO] and [Setting IP Address Restriction] are completed, the information processing of the SSO sequence in FIG. 4 can be started.

The SSO sequence of this embodiment of FIG. 4 starts from the following. That is, based on a user operation, the web browser 220 on the client PC 200 accesses the URL of the service provider 400 in order to use the application server 460 of the service provider 400 (S4.1). The URL is as follows.
(Table 5: RelayState URL)
"
https: // application. sp. example. com / portal. html
"

Since the user is now set to SSO and is not logged in, the SSO management module 450 of the service provider 400 generates an authentication request message (SAML Request) and redirect HTML (S4.2). The authentication request message is as shown in Table 6 below.
(Table 6: Authentication request message (SAML Request))
"
<Samlp: AuthnRequest xmlns: samlp = “urn: oasis: names: tc: SAML: 2.0: protocol” xmlns: sam = “urn: oasis: names: tc: SAML: 2.0: assertion” ID = ”pfx41 -E612-8c50-9960-1b16f15741b3 "Version =" 2.0 "ProviderName =" SP test "IssueInstant =" 2016-07-16T23: 52: 45Z "Destination =" http: //idp.example.com.SSOSv " php "ProtocolBinding =""urn: oasis: names: tc: SAML: 2.0: bindings: HTT -POST "AssertionConsumerServiceURL =" http://sp.example.com/demo1/index.php?acs ">
<Sam: Issuer> http: // sp. example. com / demo1 / metadata. php </ saml: Issuer>
<Ds: Signature xmlns: ds = "http://www.w3.org/2000/09/xmldsig#">
<Ds: SignedInfo>
<Ds: Canonicalization Method Algorithm = "http://www.w3.org/2001/10/xml-exc-c14n#" / >>
<Ds: SignatureMethod Algorithm = "http://www.w3.org/2000/09/xmlmlsig#rsa-sha1"/>
<Ds: Reference URI = “# pfx41d8ef22-e612-8c50-9960-1b16f15741b3”>
<Ds: Transforms>
<Ds: Transform Algorithm = “http://www.w3.org/2000/09/xmlssig#enveloped-signature” />
<Ds: Transform Algorithm = “http://www.w3.org/2001/10/xml-exc-c14n#” />
</ Ds: Transforms>
<Ds: Digest Method Algorithm = "http://www.w3.org/2000/09/xmlssig#sha1"/>
<Ds: DigestValue> yJN ... YFI = </ ds: DigestValue>
</ Ds: Reference>
</ Ds: SignedInfo>
<Ds: SignatureValue> g5eM9yPnKsmm ... YgmB3socPqAi2Qf97E = </ ds: SignatureValue>
<Ds: KeyInfo>
<Ds: X509Data>
<Ds: X509 Certificate> MIICaj ... Hop1nErV6Q == </ ds: X509 Certificate>
</ Ds: X509Data>
</ Ds: KeyInfo>
</ Ds: Signature>
<Samlp: NameIDPolicy Format = “urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress” AllowCreate = “true” />
<Samlp: RequestedAuthnContext Comparison = “exact”>
<Sam: AuthnContextClassRef> urn: oasis: names: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport </ sam: AuthnContextClassRef>
</ Samlp: RequestedAuthnContext>
</ Samlp: AuthnRequest>
"

The SAML Request is expressed by an <AuthnRequest> element with an embedded signature defined in the SAML 2.0 specification. In addition, HTTP POST Binding is used for transmitting the authentication request message. Therefore, the SSO management module 450 of the service provider 400 generates a redirect HTML including the authentication request message of Table 7 by Base64 encoding the generated authentication request message of Table 5 (S4.2). Then, the SSO management module 450 responds to the client PC 200 so that the IdP registered in [SP side: trusted IdP registration] redirects to a URL that accepts an authentication request (S4.3).
(Table 7: Redirect HTML including authentication request message)
"
<Html>
<Head>
<Title> Access rights validated </ title>
</ Head>
<Body onload = “document.forms [0] .submit ()”>
<Form method = “post” action = “https &#x3a;&#x2f;&#x2f; sooa.my.salesforce.com &#x2f; idp &#x2f; endpoint &#x2f;Httppost”>
<Input type = "hidden" name = "SAMLRequest" value = "PHNhbWxwOkF1dGhuUmVxdWVzdCAgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1M &#xd;&#xa; OjIuMDpwcm90b2NvbCIKSUQ9InMyM2VlMWE5Njk1OGM5ZWNkOWZjYmQ0ODFhNGFlYTA1NTRhNjNj &#xd;&# .... &#x2b; Cjwvc2FtbHA6 &#xd;&#xa; QXV0aG5SZXF1ZXN0Pg &#x3d;&#X3d;"//>
<Input type = “hidden” name = “RelayState” value = “https://application.sp.example.com/portal.html“ //>
<Noscript>
<Center>
<Input type = “submit” value = “Submit” //
</ Center>
</ Noscript>
</ Form>
</ Body>
</ Html>
"

The redirect HTML including the authentication request message in Table 7 includes a RelayState that is an access point of the SP after SSO. In this embodiment, RelayState is the URL shown in Table 5.
The Web browser 220 of the client PC 200 that has received the redirect HTML including the authentication request message shown in Table 7 performs the following processing. In other words, the Web browser 220 of the client PC 200 redirects to the ID provider 300 indicated by the URL for accepting the authentication request by the IdP registered in [SP side: trusted IdP registration] for user authentication (S4.4).
As a result of the redirection by the client PC 200, the ID provider 300 that has received the authentication request message in Table 7 generates a user authentication using a user name and password, an IP address restriction, and an authentication response message (S4.7).
FIG. 5 is a flowchart illustrating an example of the IdP side login process of the ID provider 300. Hereinafter, the process of S4.7 will be described in detail with reference to the flowchart of FIG.
The flowchart of FIG. 5 starts when the authentication module 330 of the ID provider 300 receives the authentication request message 7 via the Web API server 320 (S501). Upon receiving the authentication request message, the authentication module 330 displays a user authentication screen, and performs user authentication using the user name and password input via the user authentication screen (S502). Then, the authentication module 330 determines whether or not the login is successful (S503). If the user is normally authenticated and it is determined that the login is successful (Yes in S503), the authentication module 330 further performs IP address restriction processing (S504). On the other hand, if the login fails (No in S503), the authentication module 330 generates a login error message (S508) and ends the process shown in FIG. The IP address restriction process is performed as follows. That is, the authentication module 330 of the ID provider 300 analyzes the HTTP header used in the redirect HTML communication including the authentication request message redirected by the HTTPS protocol received in S501. The authentication module 330 acquires a forwarded (or X-forwarded-For) header field to acquire an access source IP address, and performs IP address restriction. The Forwarded (or X-Forwarded-For) header field generally has the following format.
(Table 8: Format of Forwarded (or X-Forwarded-For) header field)
"
X-Forwarded-For: client1, proxy1, proxy2
"
The Forwarded (or X-Forwarded-For) header field is a list of IP addresses separated by commas and spaces. When a proxy server exists between the client PC 200 and the ID provider 300, the IP addresses of the respective proxy servers that have passed through are sequentially recorded on the right side of the IP address of the client PC 200. In the present embodiment, the IP address in the leftmost column of the Forwarded (or X-Forwarded-For) header field is used as the access source IP address.

  The authentication module 330 acquires the user ID of the user authenticated in S502 and the IP address of the client PC 200 in the Forwarded (or X-Forwarded-For) header field. Then, the authentication module 330 refers to the IdP side IP address restriction setting table of Table 3 existing in the DB module 340. The authentication module 330 acquires an access permission IP address corresponding to the user ID in Table 3 corresponding to the authenticated user ID. Then, the authentication module 330 determines whether the access source IP address matches the connection permission IP address corresponding to the user ID in Table 3 or is included in the IP address range (S505). As a result of the determination, if the IP address of the access source client PC 200 included in Forwarded (or X-Forwarded-For) matches the access-permitted IP address or is included in the IP address range (Yes in S505), the authentication module 330 Advances to S506. In other words, the access source client PC 200 assumes that access is permitted, and the authentication module 330 generates an authentication response message (SAML Response) (S506). If the IP address of the access source client PC 200 included in Forwarded (or X-Forwarded-For) does not match the access-permitted IP address or is not included in the IP address range (No in S505), the authentication module 330 An IP address restriction error message is generated as an address restriction error (S507), and the process shown in FIG. 5 ends.

The authentication response message generated by the authentication module 330 in S506 is as follows.
(Table 9: Authentication Response Message (SAML Response))
"
<Samlp: Response xmlns: samlp = “urn: oasis: names: tc: SAML: 2.0: protocol” xmlns: sam = “urn: oasis: names: tc: SAML: 2.0: assert6 ID67” 367 “Version =“ 2.0 ”IssueInstance =“ 2014-07-17T01: 01: 48Z ”Destination =“ http://sp.example.com/demo1/index.php?acs ”InResponseTo =“ ONELOG101 — 3FE4 356
<Sam: Issuer> http: // idp. example. com / metadata. php </ saml: Issuer>
<Samlp: Status>
<Samlp: StatusCode Value = "urn: oasis: names: tc: SAML: 2.0: status: Success">
</ Samlp: Status>
<Sam: Assessment xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xs = "http://www.w3.org/2001/XMLSchema" ce = 9 pfx7 −7e3f-7ff1-aac962e10f46 ”Version =“ 2.0 ”IssueInstance =“ 2014-07-17T01: 01: 48Z ”>
<Sam: Issuer> http: // idp. example. com / metadata. php </ sam: Issuer><ds: Signature xmlns: ds = "http://www.w3.org/2000/09/xmlssig#">
<Ds: SignedInfo><ds: Canonicalization Method Algorithm = "http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Ds: SignatureMethod Algorithm = "http://www.w3.org/2000/09/xmlmlsig#rsa-sha1"/>
<Ds: Reference URI = “# pfxcece9a75-ff7f-7e3f-7ff1-aac962e10f46”><ds:Transforms><ds: Transform Algorithm = “http://www.w3.org/vd.e. "/ >><ds: Transform Algorithm ="http://www.w3.org/2001/10/xml-exc-c14n#"/>></ ds: Transforms><ds: DigestMethod Algorithm =" http: // www.w3.org/2000/09/xmlmlsig#sha1"/><ds:DigestValue>zV9R...h7EIlJjlDqg </ Ds: DigestValue></ ds: Reference></ ds: SignedInfo><ds:SignatureValue> WwwsViXvC7 ... qx + FRJYZnAY = </ ds: SignatureValue>
<Ds: KeyInfo><ds:X509Data><ds:X509Certificate> MIICajCCAdOgA ... YZGyc4LzgD0CROMASTWNg == </ ds: X509Certificate></ ds: X509Data> / ds: X509Data: / s: X509Data
<Sam: Subject>
<Sam: NameID SPNameQualifier = “http://sp.example.com/demo1/metadata.php” Format = “urn: oasis: names: tc: SAML: 2.0: nameid-format: transient <U> sam: NameID>
<Sam: Subject Information Method = “urn: oasis: names: tc: SAML: 2.0: cm: bearer”>
<Sam: SubjectConfigurationData NotOnOrAfter = “2026-01-18T06: 21: 48Z” Recipient = “http://sp.example.com/demo1/index.php?
</ Saml: Subject Confirmation>
</ Saml: Subject>
<Sam: Conditions NotBefore = “2016-07-17T01: 01: 18Z” NotOnOrAfter = “2026-01-18T06: 21: 48Z”>
<Saml: AudienceRestriction>
<Sam: Audience> http: // sp. example. com / demo1 / metadata. php </ sam: Audience>
</ Saml: AudienceRestriction>
</ Saml: Conditions>
<Sam: AuthnStatement AuthnInstant = “2016-07-17T01: 01: 48Z” SessionNotOnOrAfter = “2026-07-17T09: 01: 48Z” SessionIndex = “_ be99967abd904def71e3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef3ef0ef3ef3ef3ef0ef3ef3ef3ef3ef3ef093
<Saml: AuthnContext>
<Sam: AuthnContextClassRef> urn: oasis: names: tc: SAML: 2.0: ac: classes: Password </ sam: AuthnContextClassRef>
</ Saml: AuthnContext>
</ Saml: AuthnStatement>
<Saml: AttributeState>
<Sam: Attribute Name = “uid” NameFormat = “urn: oasis: names: tc: SAML: 2.0: attrname-format: basic”>
<Sam: AttributeValue xsi: type = “xs: string”> test </ sam: AttributeValue>
</ Saml: Attribute>
<Sam: Attribute Name = “mail” NameFormat = “urn: oasis: names: tc: SAML: 2.0: attrname-format: basic”>
<Sam: AttributeValue xsi: type = “xs: string”> test @ example. com </ saml: AttributeValue>
</ Saml: Attribute>
<Sam: Attribute Name = “eduPersonAffiliation” NameFormat = “urn: oasis: names: tc: SAML: 2.0: attrname-format: basic”>
<Sam: AttributeValue xsi: type = "xs: string"> users </ sam: AttributeValue>
<Sam: AttributeValue xsi: type = "xs: string"> example1 </ sam: AttributeValue>
</ Saml: Attribute>
</ Saml: AttributeState>
</ Saml: Assertion>
</ Samlp: Response>
"

In the present embodiment, the SAML Response is expressed by an <AuthnResponse> element in accordance with the SAML 2.0 specification. The authentication response message uses <Id: Signature xmlns: ds = "http: //www.w3" in Table 9 using the IdP private key used for the signature of the authentication response message for each SSO user in accordance with the SAML 2.0 specification. .Org / 2000/09 / xmldsig # "> Assertion signatures according to the XML Signature standard are given as follows.
In addition, HTTP POST binding is used for transmitting the authentication response message. Therefore, the SSO management module 350 of the ID provider 300 generates a redirect HTML including the authentication response message of Table 10 by Base64 encoding the generated authentication response message of Table 9.
Here, the description of FIG. 4 is resumed. In S4.7, the authentication response message in S506 of FIG. 5 is Base64-encoded to generate redirect HTML including the authentication response message in Table 10 below. After S4.7, the ID provider 300 responds to the client PC 200 so that the SP registered in [IdP side: trusted SP registration] redirects to a URL that accepts an authentication response (S4.8).

(Table 10: Redirect HTML including authentication response message)
"
<Html xmlns = “http://www.w3.org/1999/xhtml” xml: lang = “en”>
<Body onload = “document.forms [0] .submit ()”>
<Noscript>
<P>
<Strong> Note: </ strong> Since your browser does not support JavaScript,
you must press the Continue button once to processed.
</ P>
</ Noscript>
<Form action = "https://de01.auth.a01.c-aas-test.com/auth/Sam/SP/SSO/Post" method = "post">
<Div>
<Input type = “hidden” name = “RelayState” value = “https://application.sp.example.com/portal.html“ //>
<Input type = “hidden” name = “SAML Response” value = “PD94bWwgdmVyc2lvbj0iMS4wIilbmNvZGluZZz0iVVR ... dHJpY3Rpb24 + PHNhbWw9QV2HcUQV2H2UcVHQU2VcHQR
</ Div>
<Noscript>
<Div>
<Input type = "submit" value = "Continue"/>
</ Div>
</ Noscript>
</ Form>
</ Body>
</ Html>
"

The redirect HTML including the authentication response message in Table 10 includes a RelayState that is an access point of the SP after SSO. In this embodiment, RelayState is the URL shown in Table 5.
The Web browser 220 of the client PC 200 that has received the redirect HTML including the authentication response message shown in Table 10 is a service indicated by the URL for accepting the authentication request by the SP registered in [IdP side: trusted SP registration] for user authentication. Redirect to the provider 400 (S4.9).
As a result of the redirection by the client PC 200, the service provider 400 that has received the authentication request message in Table 10 performs SP side authentication processing (S4.10) that skips IP address restriction, verifies the authentication response message, and performs user authentication.

FIG. 6 is a flowchart illustrating an example of information processing by the service provider 400. Hereinafter, the process of S4.10 will be described in detail with reference to the flowchart of FIG.
The flowchart in FIG. 6 starts when the authentication module 430 of the service provider 400 receives the authentication response message in Table 10 as an authentication message via the Web API server 420 (S601). The authentication module 430 that has received the authentication response message determines whether or not the authentication message received in S601 is SSO (S602). If the authentication message is HTML including an authentication response message (SAML Response) as shown in Table 10, it is determined to be SSO (Yes in S602), and the authentication module 430 proceeds to S610. The SSO management module 450 skips the access source IP address restriction process for the service provider 400 performed with reference to the value set in [SP side: IP address restriction setting], and performs the authentication response message verification process ( S610). On the other hand, if the authentication message received in S601 is not the authentication response message in Table 10 but the user name and password by the normal login process of the service provider 400, it is determined that the authentication message is not SSO (No in S602), and the authentication module 430 determines that the authentication module 430 is S606. Proceed to Then, the authentication module 430 performs an access source IP address restriction process (S606) for the service provider 400, which is performed by referring to the value set in [SP side: IP address restriction setting].

Here, according to the sequence of FIG. 4, when the authentication message received in S601 is the authentication response message of Table 10 indicating that it is SSO, the SSO management module 450 performs an authentication response verification process. The authentication response verification process of S610 is, SSO management module 450 is shown from the authentication response message of Table 10 received in the value = of <input type = "hidden" name = "SAMLResponse" value = "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVR ... dHJpY3Rpb24 + PHNhbWw6QXVkaWVuY2U + aHRzcG9uc2U +"/> The contents of the SAML Response are extracted, decoded and verified to determine whether the verification is successful. The value of SAML Response is a value obtained by Base64 encoding the authentication response message shown in Table 9 by the SSO management module 350 of the ID provider 300. The SSO management module 450 decodes the content of the SAML Response 64 by Base64, and obtains an authentication response message shown in Table 9.
In this embodiment, SAML Response follows the SAML 2.0 specification. The SSO management module 450 uses the IdP public key (for signature verification using the IdP private key included in the authentication response from the IdP) for each SSO user, and <ds: Signature xmlns: ds = “http://www.w3.org/2000/09/xmlssig#”> The assertion signature is verified in accordance with the XML Signature standard as follows.

The SSO management module 450 uses <sam: NameID SPNameQualifier = “http://sp.example.com/demo1/metadata.php” Format = of the authentication response message in Table 9 as the SSO user name used in the verification. “User0001” included in “urn: oasis: names: tc: SAML: 2.0: nameid-format: transient”> User0001 </ sam: NameID> is used.
The SSO management module 450 determines whether or not the authentication response verification process has ended normally (S611). If it is determined that the authentication response verification process has been completed normally (Yes in S611), the authentication module 430 performs a login process to the service provider 400 using the SSO user name (S603). When the SSO authentication response message is processed normally as in S4.10, in the login process, the authentication module 430 authenticates the login without performing password verification (Yes in S604) and returns a login success message (S605). ). Then, the authentication module 430 ends the process of FIG. If the authentication response verification process in S610 does not end normally (No in S611), the authentication module 430 displays a login error screen and ends the process shown in FIG. 6 (S609).

  After finishing the processing of S4.10 of FIG. 4 described in detail with reference to the flowchart of FIG. 6, the SSO management module 450 of the service provider 400 performs <input type = “hidden” name = “RelayState” value = “https” in Table 10. //Application.sp.example.com/portal.html “/> The URL that is the value of the RelayState included in the Web browser 220 of the client PC 200 so as to perform a redirect process together with an access token for using the service. A response is returned to (S4.13). The web browser 220 of the client PC 200 that has received the response accesses the redirect URL of the service provider 400 indicated by RelayState with an access token (S4.14). Then, the web browser 220 accesses the application server 460 that is the web application of the service provider 400 and starts using the application service.

FIG. 7 is a login sequence diagram for using, for example, a user on the service provider, a service related to the SSO setting, which is performed by the user logging in directly to the service provider 400. The web browser 220 of the client PC 200 accesses the web API server 420 of the service provider 400 in order to log in to the service provider 400 (S7.1). Upon receiving the login information, the Web API server 420 of the service provider 400 calls the authentication module 430 and performs login authentication processing (S7.2). The authentication module 430 of the service provider 400 analyzes the HTTP header when receiving the login information together with the user name and password received in S601. Then, the authentication module 430 acquires a forwarded (or X-forwarded-For) header field to acquire an access source IP address, and performs IP address restriction (S606).
The Forwarded (or X-Forwarded-For) header field is a list of IP addresses separated by commas and spaces. When a proxy server exists between the client PC 200 and the service provider 400, the IP address of each proxy server that has passed through is sequentially recorded on the right side of the IP address of the client PC 200. In the present embodiment, the IP address in the leftmost column of the Forwarded (or X-Forwarded-For) header field is used as the access source IP address.

The authentication module 430 acquires the user ID of the user acquired in step 601 and the IP address of the client PC 200 in the Forwarded (or X-Forwarded-For) header field. The authentication module 430 refers to the SP side IP address restriction setting table of Table 4 existing in the DB module 440. The authentication module 430 acquires an access permission IP address corresponding to the user ID of Table 4 corresponding to the authenticated user ID, and the access source IP address matches the connection permission IP address corresponding to the user ID of Table 4 or IP It is determined whether it is included in the address range (S607). As a result of the determination, if the IP address of the access source client PC 200 included in Forwarded (or X-Forwarded-For) matches the access-permitted IP address or is included in the IP address range (Yes in S607), the authentication module 430 Advances to S603. The authentication module 430 performs login processing by assuming that the access source client PC 200 is permitted to access (S603). When the IP address of the access source client PC 200 included in Forwarded (or X-Forwarded-For) matches the access-permitted IP address or is not included in the IP address range (No in S607), the authentication module 430 performs S608. Proceed to The authentication module 430 displays an IP address restriction error message as an IP address restriction error (S608), and ends the process shown in FIG.
If it is determined Yes in S607 and the process proceeds to S603, the authentication module 430 verifies the user ID and password received in S601 and the user ID and password registered in the DB module 440 in advance, and performs login processing. I do. The authentication module 430 determines whether the login is not successful as a result of the verification (S604). If the login is successful (Yes in S604), the authentication module 430 performs a login success process (S605) and ends the process shown in FIG. If the login in S603 is not successful (No in S604), the authentication module 430 displays a login error screen (S609) and ends the process shown in FIG.

  After finishing the process of S7.2 of FIG. 7 detailed with the flowchart of FIG. 6, the SSO management module 450 of the service provider 400 performs the following process. That is, the SSO management module 450 returns a response to the Web browser 220 of the client PC 200 so as to perform a redirect process for the URL included in S7.1 together with an access token for using the service (S7.3). . The web browser 220 of the client PC 200 that received the response accesses the redirect URL of the service provider 400 included in S7.1 with an access token. Then, the web browser 220 accesses the application server 460, which is a web application of the service provider 400, and starts using the application service (S7.4).

<Embodiment 2>
[Default IP address restriction for SP side login for users with SSO settings]
After completion of [Building trust relationship between IdP and SP in SSO] and [Setting IP address restriction], the login sequence to the service provider 400 of FIG. 7 can be started.
FIG. 7 is a login sequence diagram for using, for example, a user on the service provider, a service related to the SSO setting, which is performed by the user logging in directly to the service provider 400. The web browser 220 of the client PC 200 accesses the web API server 420 of the service provider 400 in order to log in to the service provider 400 (S7.1). Upon receiving the login information, the Web API server 420 of the service provider 400 calls the authentication module 430 and performs login authentication processing (S7.2).

FIG. 8 is a flowchart of the login authentication process by the service provider 400 in S7.2.
The flow shown in FIG. 8 starts when the authentication module 430 of the service provider 400 receives login information (S801) in S7.2. Here, the authentication module 430 determines whether the received login information is HTML for redirection including an authentication response message as shown in Table 10 indicating login by SSO, or is a user name / password that is normal login information. (S802). If the login is by SSO (Yes in S802), the authentication module 430 performs a login process (S803) in the same manner as S603 and after in the first embodiment. If it is determined that the login information received in S801 is a user name / password that is normal login information (No in S802), the authentication module 430 checks whether or not the user is set to SSO (S810). More specifically, the authentication module 430 confirms the SSO setting by storing the SP metadata information and the secret stored in the DB module 440 by associating the user name with the user in [SP side: trusted IdP registration]. This is done by confirming the existence of the key. The authentication module 430 assumes that the user is set for SSO if SP metadata or the like is present in the confirmation, and that the user is not set for SSO if there is no SP metadata or the like. The SSO setting is an abbreviation for single sign-on setting.

If the user ID of the user received in S801 is not set as SSO (No in S810), the authentication module 430 performs IP address restriction processing as shown in S606 of FIG. 6 of the first embodiment (S806). When the IP address restriction process of S806 is successful (Yes in S807), the authentication module 430 performs the login process after S803. On the other hand, when the IP address restriction process of S806 has failed (No in S807), the authentication module 430 displays an IP address restriction error screen (S808) and ends the process of FIG.
When the user ID of the user received in S801 is set as SSO (Yes in S810), the authentication module 430 sets the IP address restriction of the user indicated in [SP side: IP address restriction setting] or is not set. Even in the state, the default IP address restriction is performed (S811). The default IP address restriction is performed by making the following settings in the DB module 440 in advance and referring to the authentication module 430 in S811. As shown in S606 of FIG. 6 in the first embodiment, the access module IP address of the authentication request source client PC 200 subject to the IP address restriction is obtained by the authentication module 430 in the Forwarded (or X-Forwarded- For) The IP address of the client PC 200 in the header field is acquired. S810, S806, and S811 are examples of processing for changing the IP address control processing depending on whether or not the user is set to single sign-on when it is determined that single sign-on is not performed based on the authentication message. .

(Table 11: Default IP address restrictions)
"
User ID: Access-permitted IP address User0001: 192.168.100. *
User0001: 172.20.0. *-172.20.128. *
"

The default IP address restriction setting table on the service provider 400 side of Table 11 shows that when User0001 accesses IdP, the range of 192.168.100.0/16 as the access source IP address, and 172.2.0.0.0 to 172 Allow IP address range up to 20.128.255.
The feature of this embodiment is that if the user is set to SSO when logging in to the service provider 400, the user's IP address shown in [SP side: IP address restriction setting]. Even when the restriction is set or not set, the default IP address restriction is performed.
If the authentication module 430 succeeds in the default IP address restriction process in S811 (Yes in S807), the login process in S803 and subsequent steps is performed. On the other hand, when the default IP address restriction process of S811 fails (No in S807), the authentication module 430 displays an IP address restriction error screen (S808) and ends the process of FIG.
The login processing after S803, that is, S803, S804, S805, and S809, is the same as S603, S604, S605, and S609 in FIG. 6 of the first embodiment.

<Other embodiments>
The present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium. It can also be realized by a process in which one or more processors in the computer of the system or apparatus read and execute the program. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

  As mentioned above, although preferable embodiment of this invention was explained in full detail, this invention is not limited to the specific embodiment which concerns.

  As described above, according to the processing of each embodiment described above, the following can be performed. In other words, when implementing IP address restrictions at the time of login on both the ID provider (IdP) side and the service provider (SP) side in a single sign-on (SSO) capable system, the consistent operation of the IP address restrictions is realized. User convenience can be improved. More specifically, according to the IP address restriction policy on the IdP side, even if the IP address restriction is set on the SP side, it is not determined. For the user, the IP address restriction operation is consistent with the policy on the IdP side. Further, for the system, it is possible to prevent useless operations on the SP side (processing when settings are different between IdP and SP).

300 ID provider 400 Service provider

Claims (11)

Receiving means for receiving an authentication message from the client device;
When it is determined that the single sign-on is based on the authentication message, the IP address restriction process is omitted. When it is determined that the single sign-on is not based on the authentication message, the IP address restriction process is executed. Control means;
An information processing apparatus on the service provider side. A determination means for determining whether or not single sign-on is based on the authentication message;
The control unit omits the IP address restriction process when the determination unit determines that the single sign-on is performed, and executes the IP address restriction process when the determination unit determines that the single sign-on is not performed. The information processing apparatus on the service provider side according to claim 1.   When the authentication message is an authentication response message generated by the information processing apparatus on the ID provider side, the determination unit determines that the authentication message is single sign-on, and the authentication message is generated by the information processing apparatus on the ID provider side. 3. The information processing apparatus on the service provider side according to claim 2, wherein if it is not an authentication response message, it is determined that it is not single sign-on.   4. The control unit according to claim 1, wherein, when it is determined that the single sign-on is not performed based on the authentication message, the control unit changes the IP address control process according to whether or not the user is set to single sign-on. An information processing apparatus on the service provider side according to any one of the preceding claims.   5. The information processing apparatus on the service provider side according to claim 4, wherein the control means executes control processing of a default IP address when the user is set to single sign-on. An information processing method executed by an information processing apparatus on a service provider side,
A receiving step of receiving an authentication message from the client device;
When it is determined that the single sign-on is based on the authentication message, the IP address restriction process is omitted. When it is determined that the single sign-on is not based on the authentication message, the IP address restriction process is executed. Control steps;
An information processing method including: A determination step of determining whether single sign-on is based on the authentication message;
In the control step, when it is determined that the single sign-on is determined in the determination step, the IP address restriction process is omitted, and when it is determined that the single sign-on is not determined in the determination step, the IP address restriction process is executed. The information processing method according to claim 6.   In the determination step, if the authentication message is an authentication response message generated by the information processing device on the ID provider side, it is determined that single sign-on is performed, and the authentication message is generated by the information processing device on the ID provider side. The information processing method according to claim 7, wherein if it is not an authentication response message, it is determined that it is not single sign-on.   9. The control process according to claim 6, wherein in the control step, when it is determined that the single sign-on is not performed based on the authentication message, the IP address control process is changed according to whether or not the user is set to single sign-on. The information processing method according to any one of the preceding claims.   The information processing method according to claim 9, wherein in the control step, when the user is set to single sign-on, control processing of a default IP address is executed.   The program for functioning a computer as each means of the information processing apparatus by the side of the service provider in any one of Claims 1 thru | or 5.

Images