Bug #640

Open eCard App - Unterstützung SAML Attached TcToken

Added by Michael Stoll about 1 year ago. Updated 7 months ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Build Version:


Entsprechend Spezifikation TR3130 Part 1 Kap 4.2.2 ("The SAML Processor MAY also be operated attached to the eID-Server thus using just one communication channel to the eID-Client") wurde bei unserem eID Server der PSK Port abgeschaltet. Seitdem ist die Open eCard App nicht mehr funktionsfähig. Es scheint so zu sein, das die Open eCard App den entsprechende TcToken nicht korrekt verarbeitet.

Der TcToken des Servers:

Es wird ein SOP Prüfung durchgeführt die an dieser Stelle nach Spezifikation nicht gefordert ist.
Der ServiceProvider und der eID Service müssen nicht der SOP entsprechen.

Stelle im Quellcode: TCTokenVerifier:assertSameChannel

richclient_info - SAML Attached.log Magnifier (27.5 KB) Michael Stoll, 03/06/2018 11:17 AM

saml_attached.png (39.1 KB) Tobias Wich, 03/09/2018 11:55 AM

com2.png (14.7 KB) Tobias Wich, 08/25/2018 10:23 PM

com1.png (139 KB) Tobias Wich, 08/25/2018 10:23 PM

samlc1.png (23.2 KB) Tobias Wich, 08/25/2018 10:30 PM

samls1.png (125 KB) Tobias Wich, 08/25/2018 10:56 PM


#1 Updated by Tobias Wich about 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Detlef Hühnlein

As pointed out in the issue, the problem is in the TCTokenVerifier.assertSameChannel function. As the comment explains, the interpretation when the code was written assumed a strong coupling between the TCToken Address and the PAOS Server.
We will revise the relevant parts of the specification and decide whether this is an allowed behaviour or not.

    private void assertSameChannel(String name, String address) throws InvalidRedirectUrlException,
        InvalidTCTokenUrlException, SecurityViolationException {
    // check that everything can be handled over the same channel
    // TR-03124-1 does not mention that redirects on the TCToken address are possible and it also states that there
    // are only two channels. So I guess we should force this here as well.
    URL paosUrl = assertURL(name, address);
    List<Pair<URL, TlsServerCertificate>> urls = ctx.getCerts();
    for (Pair<URL, TlsServerCertificate> next : urls) {
        if (! TR03112Utils.checkSameOriginPolicy(paosUrl, next.p1)) {
        String minor = ResultMinor.COMMUNICATION_ERROR;
        String errorUrl = token.getComErrorAddressWithParams(minor);
        throw new SecurityViolationException(errorUrl, FAILED_SOP);

#3 Updated by Detlef Hühnlein about 1 year ago

  • Assignee changed from Detlef Hühnlein to Michael Stoll
  • Reviewer set to Tobias Wich

TR-03124-1 (page 7, section 2.1, right above figure 2) states:
"In the special case of both channels TLS-1 and TLS-2 terminating at the same domain (“Attached eID-Server”), the intermediary channel TLS-1-2 is not necessary."

This is not the case in the present example, as and and
hence it seems to be fully in line with TR-03124 that the Open eCard App yields a corresponding error here.

If that works with other eID-Clients, this would indicate that there is a test case missing in TR-03124-2. ;-)

#4 Updated by Michael Stoll about 1 year ago

Es geht nicht um "Attached eID-Server" sondern um SAML (TR 03124-1 Kap 26. Seite 18).
Hier steht leider nichts zu SAML Attached, die Spezifikation verweist aber auf [TR-03130], part 1.
Statt 2 TLS-2 Kanäle (eID-Client - SAML Prozessor und eID-Client - eID-Server) wird nur noch ein TLS-2 Kanal genutzt. Es geht nicht um die Kanäle TLS-1 und TLS-1-2.
Ich habe das mit Patrick Schiel diskutiert und wir waren auch der Meinung, dass die Spezifikationen des BSI hier etwas verwirrend sind, da ständig zu anderen Stellen gesprungen wird.
Ich gehe davon aus, dass man etwas spezifizieren wollte, was funktioniert. Die Kombination TR3130 Part 1 Kap 4.2.2 (hat Governikus im eID Server umgesetzt) und TR-03124-1 Kap. 2.1 (OpeneCard APP) kann nicht funktionieren.
Bis das BSI die Spezifikationen präzisiert hat, könnte man ein weiters "Legacy Verhalten" definieren: "Erlaube SAML Attached"

#5 Updated by Tobias Wich about 1 year ago

TR-03130-1 is pretty clear about the number of channels the eID Client may establish. If the TCToken URL used in the activation and the ServerAddress in the TCToken differ, then more than one channels are needed.

#6 Updated by Michael Stoll about 1 year ago

Woher kommt die Aussage: If the TCToken URL used in the activation and the ServerAddress in the TCToken differ, then more than one channels are needed.

#7 Updated by Tobias Wich 7 months ago

As the topic came up again new specifications are available I decided to take another look at what is within the bounds of the latest specifications (TR-03124-1 v1.3 and TR-03130-1 v2.1.2). Furthermore this should act as a foundation for a discussion with the BSI and Governikus.

Client Perspective

The first thing to look at is TR-03124-1 which is the specification containing everything to know when implementing an eID client. If one leaves out the eCard API, EAC and Crypto recommendations which are not of interest for the things were talking about here.

Sec. 2.1 Communication Model describes over which channels the eID Client, the eService and the eID Server communicate.

The following pictures show the two patterns that are possible and also defines that if eService and eID Server are used in the attached scenario, then the domains of both are the same.

In the special case of both channels TLS-1 and TLS-2 terminating at the same domain (“Attached eID-Server”), the intermediary channel TLS-1-2 is not necessary. Usage of the attached model is indicated by the eService via the absence of a pre-shared key in the TC Token (see sections 2.4 and 2.5.2).

I want to stretch the fact here that the eService (TLS-1) and the eID Server (TLS-2) are operated under the same domain. And at this point in the specification we are talking about a communication pattern which should apply to the SAML case as well. Furthermore as the eID-Client detects the attached case based on the missing PSK, the whole thing can not work anymore in case the domains of the eService and the domain of SAML-Processor/eID-Server are different.

And that is the actual problem here, there is no specified way to determine the case set up in the Elster environment. Disabling the check would be not compliant to the specification. One could try to detect if there was a SAML Request in the Request Response pair returning the TCToken. But that is nothing the specification demands as it already defines the attached case as stated above.

Continuing in Sec. 2.6 SAML, we find a description of a more fine grained communication pattern of the SAML pattern which attaches the SAML-Processor to the eID-Server.

This section does not mention a special case of an attached SAML server, so from the point of view of the client implementor, the relevant part is described in Sec. 2.1. It references TR-03130-1, so lets take a look there.

Server Perspective

In TR-03130-1 we find the first mention of the attached SAML-Processor in Sec. 4.2.2 Interaction.

I is only mentioned that SAML Processor and eID-Server may be operated in attached mode. I fails to mention, that eService and eID-Server must operate under the same domain if an attached model is used. Please note that TR-03124-1 did not require that the entity delivering the TCToken must be operated under the same domain, but rather the entity operating TLS-1 and TLS-2.


The specification is indeed hard to follow and there is quite some room for interpretation. However one thing is clear to me. I can not see how an attached deployment can be in accordance with the requirement that the TLS-1 and TLS-2 must be operated under the same domain in case the domains of TLS-1 and TLS-2 differ which is checked by the code referenced in this issue. And in case I misinterpret this requirement, then there is missing a way to detect that TLS-12b (channel to SAML-Processor) and TLS-2 must be used for the domain check.

Also available in: Atom PDF