search

swedenconnect / technical-framework

Technical Specifications for the Swedish eID Framework
28 stars 3 forks source link

Issue with saved personal identity numbers for BankID IdP:s #23

Closed martin-lindstrom closed 5 years ago

martin-lindstrom commented 7 years ago

Section 3.3 and 4.2.2 of the Implementation Profile for BankID Identity Providers within the Swedish eID Framework - version 1.0 specification recommends that the IdP should save (in a cookie) a personal identity number entered during authentication for later use when the users "authenticates for signature" (BankID signature). The reason for this recommendation is that we want to avoid prompting the user for the personal identity number when he or she is performing a signature within the same web session.

Now, use cases where this recommendation may mess up the desired behaviour have been reported. Without going into any details, the problem is that a service provider wishes to let two different persons sign a contract within the same web session. One person logs in, and the two persons fill in the contract/agreement together and at the end both parties sign the contract. It is a special case, but, in either way, when person number 2 is about to sign the contract there is no way for the service provider to get the IdP to understand that it should prompt for the personal identity number. The IdP has already written the first persons personal identity number to a session cookie that resides in the browser.

The only bullet proof solution to this problem is to extend the AuthnRequest message so that signature services may pass information to the IdP about the user in question. By introducing this kind of extension we get a solution that is more dynamic for any use case and any type of technique implemented by the Identity Provider.

Razumain commented 7 years ago

It seems more appropriate and generic if the SP provides known information about the user to the IdP at each instance, rather than the IdP trying to store it in session cookies. Adding such information as optional request data seems appropriate. It does necessarily mean that storing data in cookies is bad och should be banned, but would be overridden by data provided in the the request.

martin-lindstrom commented 7 years ago

One alternative to defining a new extension for this purpose is to pass the Subject element in the AuthnRequest and there make use of the SPProvidedID. Section 2.2.2 of SAML-core states:

A name identifier established by a service provider or affiliation of providers for the entity, if different from the primary name identifier given in the content of the element. This attribute provides a means of integrating the use of SAML with existing identifiers already in use by a service provider. For example, an existing identifier can be "attached" to the entity using the Name Identifier Management protocol defined in Section 3.6.

This may not be as generic as an own datatype, but on the upside we don't have to define an extension of our own.

Razumain commented 7 years ago

A new resolution to this issue has been included in the last pull request.

martin-lindstrom commented 6 years ago

This will not make it into the June 2018 release.

martin-lindstrom commented 5 years ago

PR https://github.com/swedenconnect/technical-framework/pull/70, which is merged into the master branch now presents a draft for an AuthnRequest extension - Principal Selection in SAML Authentication Requests.