WO2013131276A1 - Procédé et appareil destinés à la transmission d'informations de sécurité - Google Patents

Procédé et appareil destinés à la transmission d'informations de sécurité Download PDF

Info

Publication number
WO2013131276A1
WO2013131276A1 PCT/CN2012/072139 CN2012072139W WO2013131276A1 WO 2013131276 A1 WO2013131276 A1 WO 2013131276A1 CN 2012072139 W CN2012072139 W CN 2012072139W WO 2013131276 A1 WO2013131276 A1 WO 2013131276A1
Authority
WO
WIPO (PCT)
Prior art keywords
tls
saml
message
assertion
certificate
Prior art date
Application number
PCT/CN2012/072139
Other languages
English (en)
Inventor
Xi Zeng
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/CN2012/072139 priority Critical patent/WO2013131276A1/fr
Publication of WO2013131276A1 publication Critical patent/WO2013131276A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the present invention relates to methods and apparatus for communicating security information. More particularly, the invention relates to methods and apparatus for using the Security Assertion Markup Language (SAML). Background
  • SAML Security Assertion Markup Language
  • OASIS Security Assertion Markup Language
  • SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.
  • This security information is expressed in the form of portable SAML assertions that applications working across security domain boundaries can trust.
  • the OASIS SAML specifications define the precise syntax and rules for requesting, creating, communicating, and using these SAML assertions.
  • SSO Single Sign- On
  • SSO gives users the ability to access more than one protected resource (such as Web pages and applications) with one authentication.
  • a user either accesses a resource at a relying party (e.g. a Service Provider), or accesses an attesting entity (e.g. an Identity Provider) such that the relying party and desired resource are understood or implicit.
  • the user authenticates (or has already authenticated) to the attesting entity, which then produces an authentication assertion (possibly with input from the relying party) and the relying party consumes the assertion to establish a security context for the user.
  • an entity In the context of SAML, an entity is an active element of a computer/network system, a principal is an entity whose identity can be authenticated, and a subject is a principal in the context of a particular security domain. A subject is at the heart of most SAML assertions, as it is the subject about which something is being asserted.
  • An asserting party is a system entity that makes SAML assertions
  • a relying party is a system entity that uses assertions it has received
  • an attesting entity is a system entity that presents an assertion (e.g. an entity that attempts to use an assertion).
  • SAML assertions carry statements about a subject/principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema.
  • SAML protocol messages are used to make the SAML-defined requests and return appropriate responses.
  • the structure and contents of these messages are defined by the SAML-defined protocol XML schema.
  • lower-level communication or messaging protocols such as HTTP or SOAP
  • a SAML assertion may contain an element called "SubjectConfirmation".
  • the ⁇ SubjectConfirmation> element provides the conditions under which an attesting entity (somebody trying to use the assertion) is permitted to do so.
  • the entity trying to use the assertion is attesting to its right to do so, usually by implying a relationship with the subject.
  • An assertion can have any number of ⁇ SubjectConfirmation> elements, but an attesting entity only has to satisfy one of them.
  • the ⁇ SubjectConfirmation> element should therefore be used by the relying party to confirm that the request or message came from a system entity that is associated with the subject of the assertion.
  • the Method attribute of the ⁇ SubjectConfirmation> element indicates the specific method that the relying party should use to make this determination.
  • One of the confirmation methods defined by SAML V2.0 is the "holder-of-key” method, for which the value of the Method attribute of the ⁇ SubjectConfirmation> element is "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key".
  • the relying party will allow any party capable of demonstrating knowledge of specific key information contained with the ⁇ SubjectConfirmationData> element of the ⁇ SubjectConfirmation> element to use the assertion (and thereby lay claim to some relationship with the subject within).
  • the specification for the Holder-of-Key Assertion Profile further defines the holder- of-key method/assertion, and specifies that the ⁇ SubjectConfirmationData> element must include one or more ⁇ ds:KeyInfo> elements, each of which holds a key or information that enables an application to obtain a key.
  • the holder of a specified key is considered to be the subject of the assertion by the asserting party.
  • Figure 1 illustrates an overview of a SSO scenario that makes use of a holder-of-key assertion.
  • the holder-of-key method/assertion involves a SAML issuer 100 (i.e. a producer of holder-of- key assertions), a presenter (i.e.
  • An attesting entity 200 is a presenter who is able to satisfy the subject confirmation requirements of the holder-of-key assertion.
  • the SAML issuer produces a holder-of-key SAML assertion using an X.509 certificate that is known to be associated with the attesting entity. To do so, the SAML issuer binds selected X.509 data from the X.509 certificate to the ⁇ ds:KeyInfo> element.
  • the attesting entity can then present the holder-of-key assertion and an X.509 certificate to the relying party, and prove possession of the private key corresponding to the public key bound to the certificate.
  • the relying party compares the X.509 data in the certificate to the X.509 data bound to the assertion, thereby confirming the attesting entity. How the SAML issuer comes to possess a certificate known to be associated with attesting entity and how the assertion and the certificate are presented to the relying party are currently outside of the scope of the SAML specifications.
  • TLS Transport Layer Security
  • the SAML specifications recommend the use of Transport Layer Security (TLS) in order to provide message integrity and confidentiality, and the authentication of the relying and asserting parties.
  • TLS Transport Layer Security
  • the TLS protocol provides privacy and data integrity between two communicating applications, and is designed to prevent eavesdropping, tampering, or message forgery.
  • TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application- specific protocols such as HTTP, FTP/FTPS, SMTP, NNTP, XMPP, LDAP etc.
  • TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.
  • the TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged.
  • figure 2 illustrates the message flow for a TLS handshake (SI) in accordance with the TLS specifications.
  • Figure 2 also illustrates an example of how support for SAML is subsequently provided by the application layer protocols, in accordance with the current standards.
  • the SAML assertion is included in a HTTP POST message sent after the TLS handshake has been completed.
  • the present invention therefore provides a method of supporting SAML for applications which run over TLS by passing the SAML assertion within the messages that form the TLS handshake, as opposed to transferring the SAML assertion in the application layer.
  • an apparatus configured to operate as a Security Assertion Markup Language (SAML) attesting entity (200).
  • SAML Security Assertion Markup Language
  • the apparatus comprises a transmitter (204) configured to send a SAML assertion to a relying party during a Transport Layer Security (TLS) handshake performed between the attesting entity and the relying party.
  • TLS Transport Layer Security
  • the apparatus may further comprise a message generation unit (205) configured to include the SAML assertion in a TLS handshake message that is to be sent to the relying party.
  • a message generation unit (205) configured to include the SAML assertion in a TLS handshake message that is to be sent to the relying party.
  • the apparatus may further comprise a receiver (203) configured to receive a TLS CertificateRequest message from the relying party, and the message generation unit (205) configured to include the SAML assertion in a TLS Certificate message that is to be sent to the relying party.
  • the receiver may be configured to receive a TLS CertificateRequest message from the relying party, the TLS CertificateRequest message including an indication that the attesting entity should provide a holder-of-key SAML assertion. If the received TLS CertificateRequest message includes an indication that the attesting entity should provide a holder-of-key SAML assertion, then the message generation unit may be configured to generate a TLS Certificate message that includes a holder-of-key SAML assertion.
  • the message generation unit may be configured not to include the digital certificate in a certificate list of the TLS Certificate message.
  • the digital certificate could be an X.509 certificate.
  • the apparatus may further comprise a SAML implementation unit (206) configured to implement the SAML protocol, including obtaining a SAML assertion, and a TLS implementation unit (207) configured to implement the TLS protocol, including implementing a TLS handshake.
  • a SAML implementation unit (206) configured to implement the SAML protocol, including obtaining a SAML assertion
  • a TLS implementation unit (207) configured to implement the TLS protocol, including implementing a TLS handshake.
  • the apparatus comprises a receiver (303) configured to receive a SAML assertion from an attesting entity during a Transport Layer Security handshake performed between the attesting entity and the relying party.
  • the receiver may be configured to receive a TLS handshake message from the attesting entity that includes the SAML assertion.
  • the apparatus may further comprise a message generation unit (305) configured to generate a TLS CertificateRequest message, and a transmitter configured to send the TLS CertificateRequest message to the attesting entity.
  • the message generation unit may be configured to include an indication that the attesting entity should provide a holder-of-key SAML assertion in the TLS CertificateRequest message that is to be sent to the attesting entity.
  • the receiver may be configured to receive a TLS Certificate message from the attesting entity, the TLS Certificate message including the holder-of-key SAML assertion and not including a digital certificate in a certificate list of the TLS Certificate message.
  • the apparatus may further comprise a SAML implementation unit (306)_ configured to implement the SAML protocol, and a TLS implementation unit (307) configured to implement the TLS protocol.
  • the SAML implementation unit may be configured to use a digital certificate included in the holder-of-key SAML assertion to confirm the attesting entity, and the TLS implementation unit may be configured to use the digital certificate included in the holder-of-key SAML assertion to perform TLS client authentication of the attesting entity.
  • a method of operating a Security Assertion Markup Language attesting entity comprises sending a SAML assertion to a SAML relying party during a Transport Layer Security handshake performed between the attesting entity and the relying party (A4).
  • the method may further comprise receiving a TLS CertificateRequest message from the relying party (A2), and sending the SAML assertion to the relying party in a TLS Certificate message (A4).
  • the TLS CertificateRequest message may include an indication that the attesting entity should provide a holder-of-key SAML assertion. If the holder-of-key SAML assertion includes a digital certificate of the attesting entity, then the TLS Certificate message sent to the relying party may include the holder-of-key SAML assertion and not include the digital certificate in a certificate list of the TLS Certificate message.
  • a method of operating a Security Assertion Markup Language relying party comprises receiving a SAML assertion from a SAML attesting entity during a Transport Layer Security handshake performed between the attesting entity and the relying party (B3).
  • the method may further comprise sending a TLS CertificateRequest message to the attesting entity (B2), and receiving the SAML assertion from the attesting entity in a TLS Certificate message (B3),
  • the TLS CertificateRequest message may include an indication that the attesting entity should provide a holder-of-key SAML assertion.
  • the TLS Certificate message received from the attesting entity may include the holder-of-key SAML assertion and may not include a certificate in a certificate list of the TLS Certificate message.
  • the method may further comprise using a digital certificate included in the holder-of-key SAML assertion to confirm the attesting entity and to perform TLS client authentication of the attesting entity (B4).
  • a computer program comprising computer program code means adapted to perform all the steps of either the third or fourth aspects when said program is run on a computer.
  • Figure 1 illustrates an overview of a scenario that makes use of a SAML holder-of-key assertion
  • Figure 2 illustrates an example message flow of a TLS handshake and a subsequent SAML exchange
  • Figure 3 illustrates an example message flow in which a SAML assertion is provided during a TLS handshake according to the methods described herein;
  • Figure 4 is a flow diagram illustrating an example of the process of a SAML attesting entity presenting a SAML assertion in accordance with the methods described herein;
  • Figure 5 is a flow diagram illustrating an example of the process of a SAML relying party obtaining a SAML assertion in accordance with the methods described herein;
  • Figure 6 illustrates schematically an example of an apparatus configured to provide a SAML attesting entity
  • Figure 7 illustrates schematically an example of an apparatus configured to provide a SAML relying party.
  • TLS Handshake protocol In order to enable a SAML assertion to be passed within the messages that form the TLS handshake, it is proposed herein to extend the TLS Handshake protocol. This is necessary because the current TLS specifications only provide support for certificate exchange and validation.
  • the TLS Certificate message sent from the client to the server would be extended to include an additional data type in order to convey the SAML assertion from the client (i.e. the attesting entity) to the server (i.e. the relying party).
  • an extended Certificate message could take the form: opaque ASN.lCert ⁇ 1..2 24-l>;
  • FIG. 3 illustrates a message flow for a full TLS handshake in which the support for SAML is provided by the TLS protocol through the use of the extended Certificate message defined above.
  • the messages defined in the TLS standard could be extended to define an additional message type, referred to as a "Certificate AndAssertion" message, which would be sent from the client to the server instead of the Certificate message and would include the SAML assertion.
  • the structure of this new message would be the same as the extended Certificate message defined above.
  • TLS CertificateRequest message sent from the server to the client would be extended to include an additional data type in order to enable the server to request a holder-of- key SAML assertion.
  • an extended CertificateRequest message could take the form: enum ⁇
  • the structure and content of the extended TLS CertificateReques message is the same as that defined in the TLS standards, the only exception being the "holder-of- key_saml_assertion" data type that is used to convey the request for a holder-of-key SAML assertion.
  • the ⁇ ds:KeyInfo> element of the SAML assertion sent to the relying party can contain the whole X.509 certificate (i.e. all of the data in the certificate) of attesting entity in the ⁇ ds:X509Certificate> element.
  • the attesting entity i.e. client
  • the attesting entity will be required to send its certificate to the relying party (i.e. server) in the Certificate message sent during the TLS handshake.
  • the attesting entity will be configured to include the holder-of-key assertion in the Certificate message but will also be configured to include it's X.509 certificate in the certificate_list structure of the Certificate message.
  • FIG. 4 is a flow diagram illustrating an example of the process of a SAML attesting entity presenting a SAML assertion in accordance with the methods described herein.
  • the steps performed are as follows: Al.
  • the attesting entity initiates a TLS handshake with the relying party.
  • the attesting entity can be configured to act as a client with respect to the implementation of the TLS protocol, and can therefore initiate a TLS handshake by sending a ClientHello message to the relying party.
  • This ClientHello message will be generated by the attesting entity in accordance with IETF RFC 5246.
  • the attesting entity receives further TLS handshake messages from the relying party (i.e. the server).
  • these messages can include a ServerHello message sent in response to the ClientHello message, a Certificate message conveying the server's certificate, and a ServerKeyExchange message.
  • the attesting entity will then receive a
  • CertificateRequest message from the relying party that requests a certificate from the attesting entity.
  • the CertificateRequest message received from the relying party may include the above-defined additional data type that requests a holder-of-key SAML assertion from the attesting entity.
  • the attesting entity processes the received CertificateRequest message and determines that it should send a SAML assertion to the relying party.
  • the attesting entity therefore obtains a SAML assertion.
  • the attesting entity can request a holder-of-key SAML assertion from a SAML issuer (e.g. an Identity Provider in an SSO scenario).
  • a SAML issuer e.g. an Identity Provider in an SSO scenario.
  • the attesting entity may have requested the SAML assertion from a SAML issuer prior to receiving the CertificateRequest message, and will therefore be able to obtain the SAML assertion from it's memory.
  • the attesting entity then continues the TLS handshake process and sends the SAML assertion to the relying party. To do so, the attesting entity generates a Certificate message and includes the SAML assertion in the Certificate message that is then sent to the relying party. If the attesting entity includes a holder-of-key SAML assertion in the Certificate message, and the holder-of-key SAML assertion includes an entire digital certificate of the attesting entity, then the attesting entity will not include the digital certificate in the certificate list of the Certificate message.
  • the certificate_list structure will therefore contain no certificates, and will have a length of zero.
  • FIG. 5 is a flow diagram illustrating an example of the process of a SAML relying party obtaining a SAML assertion in accordance with the methods described herein. The steps performed are as follows:
  • the relying party participates in a TLS handshake with the attesting entity.
  • the relying party can be configured to act as a server with respect to the implementation of the TLS protocol, and can therefore initiate a TLS handshake upon receipt of a ClientHello message from the attesting entity.
  • the relying party i.e. the server
  • TLS handshake messages to the attesting entity (i.e. the client).
  • these messages can include a ServerHello message sent in response to the ClientHello message, a Certificate message conveying the server's certificate, and a ServerKeyExchange message.
  • the relying party will then generate and send a CertificateRequest message to the attesting entity, which requests a certificate from the attesting entity.
  • the relying party may include the above-defined additional data type in the CertificateRequest message that requests a holder-of-key SAML assertion from the attesting entity.
  • the relying party then continues the TLS handshake process and sends a ServerHelloDone message to the attesting entity.
  • the relying party then receives a Certificate message from the attesting entity, sent in response to the
  • CertificateRequest message which also includes a SAML assertion.
  • the Certificate message includes a holder-of-key SAML assertion, and the holder- of-key SAML assertion includes an entire digital certificate of the attesting entity, then the certificate list of the Certificate message may contain no certificates.
  • the relying party should then use the digital certificate included in the SAML assertion to confirm the attesting entity in accordance with the SAML specifications, and should also use the digital certificate included in the SAML assertion to perform client authentication of the attesting entity in accordance with the TLS protocol.
  • the relying party then continues with the remainder of the TLS handshake, sending and receiving any further TLS handshake messages in accordance with IETF RFC
  • FIG. 6 illustrates schematically an example of an apparatus configured to provide a SAML attesting entity 200 for implementing a SAML exchange in accordance with the methods described above.
  • the attesting entity 200 can be implemented as a combination of computer hardware and software.
  • the attesting entity may be an element of a computer/network system, as defined in the SAML specifications.
  • the attesting entity 200 comprises a processor 201, a memory 202, a receiver 203 and a transmitter 204.
  • the memory 202 stores the various programs/executable files that are implemented by the processor 201, and also provides a storage unit for any required data.
  • this data can include but is not limited to a SAML assertion (e.g.
  • the programs/executable files stored in the memory 202, and implemented by the processor 201 include but are not limited to a message generation unit 205, a SAML protocol implementation unit 206 and a TLS protocol implementation unit 207.
  • FIG. 7 illustrates schematically an example of an apparatus configured to provide a SAML relying party 300 for implementing a SAML exchange in accordance with the methods described above.
  • the relying party 300 can be implemented as a combination of computer hardware and software.
  • the relying party 300 may be an element of a computer/network system, as defined in the SAML specifications.
  • the relying party 300 comprises a processor 301, a memory 302, a receiver 303 and a transmitter 304.
  • the memory 302 stores the various programs/executable files that are implemented by the processor 301, and also provides a storage unit for any required data.
  • this data can include but is not limited to security information, such as a digital certificate of an attesting entity.
  • the programs/executable files stored in the memory 302, and implemented by the processor 301 include but are not limited to a message generation unit 305, a SAML protocol implementation unit 306 and a TLS protocol implementation unit 307.
  • FIG 8 illustrates schematically an example of the software architecture 400 of a computer including the SAML implementation unit 206, 306 in accordance with the methods and apparatus described above.
  • An application 401 is served by a TLS/SSL implementation unit 207, 307 that provides TLS to the application 401.
  • the TLS/SSL implementation unit 207, 307 includes the SAML implementation unit 206, 306 in order to support the exchange of SAML assertions within the messages that form the TLS handshake.
  • the application 401 is therefore a SAML attesting entity or a SAML relying party with respect to the exchange of SAML assertions implemented by the SAML implementation unit 206, 306.
  • the operating system software (i.e. the OS Kernel) 402 bridges between the application layer and the processing done by the hardware 403, and implements a TCP/IP Stack 404 for handling any internet communication.
  • Figure 9 illustrates schematically an example of the software architecture 400 of Figure 8 implemented within a first computer 500 and a second computer 600 that communicate using the Internet 700.
  • the first computer 500 is provided with a SAML implementation unit 206 that enables the first computer 500 to obtain a SAML assertion, and provide the SAML assertion to the second computer 600 within the messages of a TLS handshake performed between the first computer 500 and the second computer 600.
  • the second computer 600 is provided with a SAML implementation unit 306 that enables the second computer 600 to receive a SAML assertion from the first computer 500 within the messages of a TLS handshake performed between the first computer 500 and the second computer 600, and to process the SAML assertion accordingly.
  • the application 401 A running on the first computer 500 is therefore a SAML attesting entity, and the application 401B running on the second computer 600 is a SAML relying party, with respect to the exchange of SAML assertions implemented by the SAML implementation units 206, 306.
  • FIG 10 illustrates schematically an example of the software architecture 400 of Figure 8 implemented within a third computer 800.
  • the software architecture 400 provides a first application 401A and a second application 401B.
  • a TLS/SSL implementation unit 207 provides a SAML implementation unit 206 that obtains a SAML assertion and provides the SAML assertion to the second application 401B within the messages of a TLS handshake performed between the first application 401 A and the second application 40 IB.
  • a TLS/SSL implementation unit 307 provides a SAML implementation unit 306 that receives a SAML assertion from the first application 401A within the messages of a TLS handshake performed between the application 401 A and the second application 40 IB, and processes the SAML assertion accordingly.
  • the first application 401A running on the computer 800 is therefore a SAML attesting entity, and the second application 401B running on the computer 800 is a SAML relying party, with respect to the exchange of SAML assertions implemented by the SAML implementation units 206, 306
  • the methods and apparatus described above provide an improved mechanism for implementing SAML that does not rely on application layer protocols to handle the SAML exchanges and therefore does not incur the high costs that would otherwise be incurred if the application layer protocols were to be individually updated.
  • the methods and apparatus described above provide that the digital certificate of the attesting entity need not be included in the certificate_list structure of the Certificate message if the entire digital certificate is also to be included in the assertion, thereby reducing the resources used.
  • the TLS handshake protocol provides a session resume mechanism.
  • both the TLS client and TLS server are required to have a session cache in which the security parameters (such as the X.509 certificate of the client) for a session are stored in association with the session ID of the session. Consequently, if the SAML assertion is transferred during the TLS handshake in accordance with the above described methods, then the cache can also store the SAML assertion data. Therefore, if the attesting entity (i.e. client) makes further attempts to access the same relying party (i.e. server), the SAML assertion does not need to be re-sent, as it is already stored in the session cache with the other security parameters of the first/original TLS session. In contrast, if the SAML assertion is originally sent in the application layer, in accordance with the current standards, then the SAML assertion will not be stored in the TLS session cache, and the attesting entity may be required to resend the SAML assertion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention se rapporte à un appareil conçu pour servir d'entité certificatrice de langage de balisage d'assertion de sécurité (SAML). Cet appareil comprend un émetteur prévu pour envoyer une assertion SAML à une partie de confiance au cours d'un établissement de liaison de sécurité de la couche transport (TLS) réalisé entre l'entité certificatrice et la partie de confiance. La présente invention a également trait à un appareil conçu pour servir de partie de confiance SAML. Ledit appareil comporte un récepteur destiné à recevoir une assertion SAML en provenance d'une entité certificatrice au cours d'un établissement de liaison TLS effectué entre l'entité certificatrice et la partie de confiance.
PCT/CN2012/072139 2012-03-09 2012-03-09 Procédé et appareil destinés à la transmission d'informations de sécurité WO2013131276A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2012/072139 WO2013131276A1 (fr) 2012-03-09 2012-03-09 Procédé et appareil destinés à la transmission d'informations de sécurité

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2012/072139 WO2013131276A1 (fr) 2012-03-09 2012-03-09 Procédé et appareil destinés à la transmission d'informations de sécurité

Publications (1)

Publication Number Publication Date
WO2013131276A1 true WO2013131276A1 (fr) 2013-09-12

Family

ID=49115890

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/072139 WO2013131276A1 (fr) 2012-03-09 2012-03-09 Procédé et appareil destinés à la transmission d'informations de sécurité

Country Status (1)

Country Link
WO (1) WO2013131276A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017212474A1 (de) * 2017-07-20 2019-01-24 Siemens Aktiengesellschaft Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010134996A2 (fr) * 2009-05-20 2010-11-25 Intertrust Technologies Corporation Systèmes et procédés de partage de contenu

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010134996A2 (fr) * 2009-05-20 2010-11-25 Intertrust Technologies Corporation Systèmes et procédés de partage de contenu

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BROWN ET AL.: "Transport Layer Security (TLS) Authorization Extensions", IETF RFC 5878, 31 May 2010 (2010-05-31) *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017212474A1 (de) * 2017-07-20 2019-01-24 Siemens Aktiengesellschaft Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus

Similar Documents

Publication Publication Date Title
KR100800339B1 (ko) 제휴 환경에서 사용자에 의해 결정된 인증 및 단일 사인온을 위한 방법 및 시스템
US8151317B2 (en) Method and system for policy-based initiation of federation management
AU2003212723B2 (en) Single sign-on secure service access
US7496755B2 (en) Method and system for a single-sign-on operation providing grid access and network access
US8528058B2 (en) Native use of web service protocols and claims in server authentication
KR101063368B1 (ko) 연합 환경에서 신원 제공자를 위한 디지털 권리 관리(ｄｒｍ) 강화 정책 관리
KR101054700B1 (ko) 연합 환경에서 서비스 제공업자를 위한 디지털 권리 관리(ｄｒｍ) 강화 정책 관리
JP4988701B2 (ja) ランタイム・ユーザ・アカウント作成オペレーションのための方法、装置、およびコンピュータ・プログラム
US8788811B2 (en) Server-side key generation for non-token clients
JP4886508B2 (ja) 既存のｓｓｌセッションを中断することなく証明書ベースの認証にステップアップするための方法及びシステム
JP5052523B2 (ja) フェデレーション内のプリンシパルの認証
US20060294366A1 (en) Method and system for establishing a secure connection based on an attribute certificate having user credentials
US20080021866A1 (en) Method and system for implementing a floating identity provider model across data centers
US8707028B2 (en) Certificate-based cookie security
WO2005032041A1 (fr) Controle d'acces pour des identites federees
GB2378010A (en) Mulit-Domain authorisation and authentication
Selkirk Using XML security mechanisms
WO2013131276A1 (fr) Procédé et appareil destinés à la transmission d'informations de sécurité
Rixon et al. IVOA SingleSignOn Profile: Authentication Mechanisms
Adams et al. Receipt-mode trust negotiation: efficient authorization through outsourced interactions
KR100992016B1 (ko) 데이터 프로세싱 시스템 내에 연합 기능성을 제공하는 방법및 장치
Berbecaru et al. Efficient Attribute Management in a Federated Identity Management Infrastructure
Pranata et al. Managing enterprise authentication and authorization permissions in digital ecosystem
Zhang et al. Survey on the Web Services Security Specifications
Peldius Security Architecture for Web Services

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12870428

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12870428

Country of ref document: EP

Kind code of ref document: A1