通过要嵌入网络应用认证周围的网络应用的方法和系统

摘要

本申请涉及一种用于通过要嵌入的网络应用认证周围的网络应用的方法和系统，周围的第一网络应用在浏览器中实施且要嵌入的第二网络应用设置用于在第一应用的单独实施和显示区域中进行，第一应用通过至少一个第一网络服务器、第二应用通过至少一个第二网络服务器提供。第一应用相对于第二应用进行认证，配属第一应用的第一秘钥材料由第二网络服务器使用，经浏览器在第一和第二网络服务器之间交换认证消息，仅在成功的认证或授权时激活第二应用。该方法实现：要嵌入的网络应用识别周围的网络应用并且其进行认证，通过存储和评估相应的网络服务器中的必要秘钥材料给予高安全标准，因为不传输秘钥材料自身而只传输用于局域使用秘钥材料的认证消息。

说明书

技术领域

本申请涉及一种用于通过要嵌入的网络应用认证周围的网络应用的方法和系统。

背景技术

如今，在工业化的设备中同时存在各种不同的系统和应用，例如SCADA(Supervisory Control and Data Acquisition，监管控制和数据获取)系统、MES(Manufactoring Execution System，制造执行系统)系统或DCS(Distributed ControlSystem，分散式控制系统)系统。在此，一些系统又由多个例如用于工程和运行的单个应用组成。同样地，在这样的设备中当然表征了域不可知的应用，例如用于通信、文档管理/处理和导航。在此，操作者必须在多个工作步骤和活动中通过各种应用结束工作。在此，多个这样的系统能作为浏览器中实施的网络应用使用。此外，这样的应用通常相互集成，以便经由共同的用户接口操作。

在此，应用通常在视觉上(即在表示层)相互集成，其特别地适用于网络应用(在此也被称为“Mash-Up”或“Mashup”(混聚))。在此，各种应用自身进一步影响其用户接口，其嵌入在上级的用户界面(User-Interface)。下列的说明特别地针对应用的应用认证，而不是自然人的认证(用户认证)。

特别地在工业化的设备中，用户/消费者或者系统集成器(System-Integratoren)常常想要使各种网络应用相互组合；然而存在各种将会反对不受控制的集成的原因。例如，各种应用的集成能够联结一个许可，然而消费者/集成器并不具有对于设备足够的许可。此外，应用能够放弃敏感的数据，从而应当保障的是，仅能够相互集成可靠的应用。

由于该原因，迄今为止常常利用工艺上的手段基本上阻止将网络应用集成到其它的(网络)应用中。最通用的变体对此原则上禁止将网络应用包含到其它的应用中，这例如由此实现，即应用识别其是否在下级的窗口、所谓的“内联框架”或简称“iframe”中实施，并且是否因此拒绝实施。此外，主要限制网络API(API＝Application ProgrammingInterface＝应用程序界面)的使用。然而在此，仅仅消费者、即API所应用的页面，相对于API进行认证。在此，典型的认证方式是API秘钥、消费者ID、授权URL或数字签名的URL。

API秘钥单独在API提供方对于每个应用要求一次，并且每个询问附加有该密钥。缺点在于，秘钥作为明文传输；因此该方法主要应用于结算(“Billing(开账单)”)。作为秘钥的替换，通常应用所谓的消费者ID(消费者识别号)。在此的转变和缺点参照API秘钥。在所谓的“授权URL”中相对于应用的API授权整个域(例如http://example.com)。在此，在调用API时传递和相对校验调用者的地址。该方式显著地取决于基础设施的特定的安装。该方法通常与其它的认证方法、例如消费者ID组合。

在此，所有这种方法都相对于服务器仅仅针对API调用，其中，该服务器并不相对于调用进行认证。

相互的认证在HTTPS/TLS中已知。然而在此，仅消费者/服务器相对认证；在此涉及用于传输通道的安全措施，其不设置产品或应用层上的认证。

同样已知了若干认证方法，它们此外被考虑用于用户认证和下游的用户授权。然而，在各种登记方法中仅检查的是，用户是允许使用具体的应用。在此并不检查是否(允许)各种应用相互联合。

在因此为周围的网络应用提供大量的措施以便对要嵌入的网络应用进行认证进而允许和封锁期间，关于关系到掌控可能性的问题存在改善需求，要嵌入的网络应用关于其周围的网络应用具有这些可能性。

发明内容

因此，本申请的目的在于，在要嵌入的网络应用方面控制其在周围的网络应用中的实施。

该目的通过一种方法和一种系统实现。

在此提出一种用于通过或相对于要嵌入的网络应用认证周围的(嵌入的)网络应用的方法和系统，其中，周围的第一网络应用在浏览器中实施，并且要嵌入的第二网络应用设置用于在周围的第一网络应用的单独的实施和显示区域中进行，其中，周围的第一网络应用通过至少一个第一网络服务器提供，并且要嵌入的第二网络应用通过至少一个第二网络服务器提供。在此，周围的第一网络应用相对于要嵌入的第二网络应用(AWB)进行认证，其中，配属于第一网络应用的第一秘钥材料能由第二网络服务器使用，其中，经由浏览器在第一网络服务器和第二网络服务器之间交换认证消息，并且其中，仅在成功的认证或授权时激活第二网络应用。借助于该方法能够实现的是，要嵌入的网络应用识别周围的网络应用，并且其自身进行认证，其中，通过存储和评估相应的网络服务器中的必要秘钥材料给予高的安全标准，因为秘钥材料自己并不被传输，而是仅交换借助于密钥材料签名的消息。由此使用秘钥材料并无需将其传输。

该目的还通过一种用于认证周围的(嵌入的)网络应用的系统实现，其中，为了实施周围的第一网络应用而设置浏览器，其中，要嵌入的第二网络应用设置用于在周围的第一网络应用的单独的实施和显示区域中进行，并且其中，设置用于提供周围的第一网络应用的第一网络服务器，并且设置用于提供要嵌入的第二网络应用的第二网络服务器。在此，该系统设计用于执行前述方法。利用这样的系统能够实现已经根据该方法阐述的优点。

在此描述的特征和其优点类似地也适用于根据本申请的系统。所述的设计方案的特征不仅能够单独地实现，也能够以显而易见的组合的方式实现。

为了安全地封装要嵌入的网络应用，有利地作为单独的实施和显示区域在周围的第一网络应用的网络窗口中应用内联框架(Inlineframe)(“iframe”)。在此有利地，在内联框架和周围的第一网络应用之间设置用于交换消息的接口。

通过在认证或授权过程中测定第一网络应用的域，能够检查认证消息的来源，其中，仅当测定了为此设置的域的时候才进行激活。

当保障了仅在认证了周围的网络应用之后才将要嵌入的网络应用的要保护的部分载入到浏览器或实施区域中时，给予更高安全性。这由此实现，即，要嵌入的第二网络应用具有带有用于与第一网络应用和/或浏览器通信并且用于与第二网络服务器通信的模块的基础部分，其中，要嵌入的第二网络应用还具有应用特定的应用部分，其中，基础部分在认证或授权之前载入到单独的实施和显示区域之中并且启动，并且其中，为了激活而将应用部分载入到单独的实施和显示区域之中并且启动或功能性接通。

附加地，也能够保护周围的网络应用防止嵌入不期望的待嵌入的网络应用，这由此实现，即，以模拟的方式相对于周围的第一网络应用认证要嵌入的第二要网络应用，其中，将配属于要嵌入的第二网络应用的第二秘钥材料存储在第二网络服务器上，并且能通过第一网络服务器借助于认证消息经由浏览器的交换使用该第二密钥材料，并且仅在第二网络应用的成功的认证或授权时加载/激活该第二网络应用(AWB)。

为了保护通信，特别是为了交换认证和授权消息，在第一和/或第二网络应用的认证或授权之前，分别在第一网络服务器和第一网络应用之间以及在第二网络应用和第二网络服务器之间设立安全的通信关系，优选地在HTTPS协议的基础上。

附图说明

接下来根据附图阐述根据本申请的方法的实施例；该实例同时用于根据本申请的系统的阐述。

在此，唯一的附图示出由具有周围和要嵌入的网络应用的浏览器组成的布置的示意图，其中，网络应用与各个网络服务器有通信关系。

具体实施方式

该附图示出了在计算机(未示出)上运行的网络浏览器(简称：浏览器)B，其经由同样未示出的网络通信地连接网络服务器WSA，WSB。在浏览器中运行第一网络应用AWA，其接下来也应当称为“周围的网络应用”并且至少部分地由第一网络服务器WSA支持(“gehostet(作主机)”)；对此类似地，接下来也应当称为“要嵌入的网络应用”的第二网络应用AWB至少部分地由第二网络服务器WSB支持(“gehostet(作主机)”)。要嵌入的第二网络应用AWB设置用于在第一网络应用AWA中在设计为“Inlineframe(内联框架)”或“iframe”的单独的实施和显示区域IF中进行。在单独的实施和显示区域IF和第一网络应用AWA之间布置用于交换消息或信息的集成接口IS。此外，通信信道KKA，KKB设立在网络应用AWA，AWB以及其分别配属的网络服务器WSA，WSB之间。在第一网络服务器WSA中存储第一秘钥材料SMA，其设置用于认证和/或授权第一网络应用AWA；可选地在第二网络服务器WSB中存储第二秘钥材料SMB，其设置用于认证和/或授权第二网络应用AWB。替代在相应的网络服务器WSA，WSB中存储相应的秘钥材料SMA，SMB，秘钥材料SMA，SMB也能够存储在另外的部件中，并且仅根据需求由网络服务器WSA，WSB调用和/或使用。

在此提出的认证始终在周围的和要嵌入的网络应用AWA，AWB之间进行。如果应将多个要嵌入的网络应用相互认证或集成，那么应用认证还是始终间接经由所有的共同的(周围的)网络应用实现，然而不直接相互实现。此外，不设置在各种的要嵌入的网络应用之间经由所述的用于使用集成接口的方式的直接通信。在当前的实例中，应当出于简明的原因仅考虑要嵌入的第二网络应用AWB。

网络应用AWB具有：各一个浏览器侧的部分，其在操作者的、也实施浏览器B的机器上实施；以及服务器侧的部分(其中在此能够涉及网络服务器或另外涉及复杂的具有位于后台(dahinterliegendem)的应用服务器或类似物的结构)，由其出发的是，其能够足够地被保护防止外部访问。

浏览器侧的部分由服务器部分提供，例如实施JavaScript代码，并且在运行时间中经由网络接口与网络服务器WSB连接。

此外，网络应用AWA影响明确规定的通信接口、集成接口IS，其用于集成第二要嵌入的网络应用。在此，要嵌入的网络应用AWB首先是基础部分，其对于所有的协作的网络应用AWB是共同的，并且因此能够是标准软件；该构件提供用于集成的基础设施并且允许例如与周围的网络应用AWA的通信。此外，网络应用AWB具有所谓的应用部分，其是应用特定的并且用于控制实际使用应用(例如经由所谓的“API Calls(API调用)”)，由应用告知结果(经由所谓的“Event-Subscriptions(事件订阅)”)并且交换数据。特别地，网络应用的该应用部分能够在认证过程中进行保护。

与此相反，在周围的网络应用AWA中通常仅存在基础接口，其用于嵌入网络应用AWB。这不仅包括视觉的集成也包括通常的通信，其是用于要嵌入的网络应用的基础接口的对应。在通信信道的成功的视觉嵌入和建立之后，网络应用AWB能够经由其特定的接口(API)使用。

对于提出的应用认证来说有利的是，周围的和要嵌入的网络应用AWA，AWB例如通过所谓的iframe相互隔绝。两个应用能够因此仅交换消息(例如借助于“postMessage”方式)并且对此做出反应。直接调用各另一个网络应用AWA，AWB的代码可靠地由浏览器B禁止。因此，消息如“postMessage”示出的原理为，在其基础上基础接口影响较高的抽象水平。

在此，认证同样经由在周围的和要嵌入的网络应用AWA，AWB之间的基础接口实现。在两个方面都能够经由普遍的“sendAuthenticationMessage(发送认证消息)”方式发送和接收(“handleAuthenticationMessage(处理认证消息)”)认证消息。经由该简单的接收能够通过消息交换(“Handshake(握手)”)实现任意的认证方法，然而在两个方面都必须能够处理相应的消息。如果接收了无效的或者未知的消息，那么就将认证做为“未认证的”结束；同样地，当在认证过程中结果为无效的认证的时候也这样。

在成功的认证之后能够在需要的情况中在此基础上建设性地进行授权，例如与在认证结果中包含的许可信息或类似物的匹配。

为了禁止例如入侵者不正当地复制或转发认证消息，能够将认证分别与域联结。因此成功的认证必须能够实现的是，向对方传输应用的域、例如作为证书的组件或类似物。在所述的iframe隔绝的情况下能够分别检查对方的域。在要嵌入的网络应用AWB的情况中，其例如通过读取浏览器B的浏览器属性“document.referrer”进行。该所谓的“Property(属性)”由浏览器B管理，在应用角度中进行写入保护(“Property(只读)”)，并且在iframes的情况中总是描述周围的网页、即网络应用AWA的URL。因此，其应当表现周围的网络应用的URL，另一方面能够从其之中提取其域。

在周围的网络应用AWA中，能够在来自于消息结果的每个postMessage通信中检查来源(“origin”)。在此涉及位于iframe中的网页、即要嵌入的网络应用AWB或其基础部分的URL，能够从其中由此提取其域。

然而在此，认证始终在相应的网络应用AWA，AWB的服务器侧实施，同样地，在那里存在有秘钥材料SMA，SMB或类似物。通过浏览器B仅对此使必要的消息通过。因此，消息的询问或随读(Mitlesen)不能够由入侵者利用，特别是通过使用受保护的通信协议如HTTPS，并且由此，通常不必使秘钥材料SMA，SMB通信，而是仅局域地在网络服务器WSA，WSB中应用。

域自身的匹配应当在相应的服务器部分中作为所谓的“握手”的子步骤进行。

如果网络应用AWA要么进行认证要么进行授权，那么就不影响网络应用AWB的应用特定的接口，或者网络应用AWB相对于其忽略相应的调用。同样地，网络应用AWB能够在其视觉区域中显示或在其它方面表现相应的信息，即在当时不能够实现应用。相反，周围的网络应用AWA不能够在可能的情况下从其用户界面(UI)中完全地去除认证/授权的网络应用AWB。

如果两个网络应用AWA，AWB之中的一个要求各另一个网络应用AWA，AWB的认证，那么其就发送相应的消息，由此开始认证过程。这应当甚至通常直接在视觉的嵌入后在网络应用的应用开始过程中发生，然而原则上在任意之后的时间点也是可能的。根据下层的认证或授权方法，该过程能够在交换一个或多个消息之后正面或负面地结束，紧接着能提供或保留、或者不提供或保留认证或授权要求的网络应用AWA，AWB、所谓的API的应用接口。

对于认证来说，相关的数据(例如私人的秘钥材料SMA，SMB)来说始终在所属的网络服务器WSA，WSB(或下层的另外的服务器)中存在，并且在那里特别地保护不进行访问。

在认证过程中能够安全地测定对方的域，例如通过将其包含在所谓的“无法伪造的声明”中来实现。应用能够如上所述测定对方的实际上的域，从而能够保障的是，认证实际上利用直接在接口上存在的应用进行。

所述方法能够扩展成两段式方式。在此，在第一阶段中例如在HTTPS的基础上保障协作的应用的值得信赖的通信。要嵌入的网络应用AWB经由iframe IF的集成在不值得信赖的源(即没有有效的证书的源)的情况下自动地禁止其进一步的结合。对此必须的置信位置由消费者在基础设施侧进行并且最初用于其安全。在完成第一阶段之后根据上述方式在第二阶段中将要相互集成的网络应用AWA，AWB、即要嵌入的网络应用AWB相对于周围的第一网络应用AWA认证，和/或相反地进行。

所提出的方式针对许可的、网络应用相互的置信位置的以及用于完整保护的开头提出的目的。此外该方式允许的是，经由普通的接口采用多个(也是所拥有的)方法并且在可能的情况下相互组合，例如将许可检查等与一般的应用认证组合。秘钥材料保留在相应的网络服务器上，并且因此不能由操作者读取。在此，经由浏览器B仅使认证消息通过，而不在那里放弃敏感的数据。

相对于已知的解决方案能够实现的是，应用要集成的网络应用AWB的接口，而不初始化服务器部分的每个调用或者公开相关的秘钥材料或类似物。相反于所谓的“ServiceAccounts(服务账号)”，网络应用AWA，AWB彼此认证，而不需要所谓的“Identity Providers(身份提供者)”形式的中心的基础设施。通常不需要干涉基础设置，或必须对其进行管理。尽管如此能够实现的是，一起接受基础设施特定的观点(例如许可)。