swedenconnect / bankid-saml-idp Goto Github PK

We should configure the SecurityFilterChain so that access to actuator endpoints is allowed - even if the actuator path is changed.

Go through documentation and make initial page + god structure.

Add config under Spring Boot Configuration in configuration.md.

Also ensure that these settings apply for the WebClient we use in rp-api.

We need to be able to distribute session data. We provide Redis-implementations that may be "turned on" using configuration settings.

For each type of health-check, document what operations should do in case or errors/warnings.

Every collect-request/response is logged on info level...

When developing the audit logging we found some minor bugs in saml-idp-spring-boot-starter Audit Logging.
These have been fixed in the main branch. When a release has been made we should use the new version as soon as possible.

As it is now we always display the Sweden Connect logo.

Current implementation only respects the Cancel button on the web application. When a user cancels via the BankId Application the server returns a 500 response since it does not stop after the cancel status has been reached.

This must be handled in both frontend and backend.

Some changes has been made and the sample needs to be updated.

Especially for local-profile and the docker compose.

There are some Thymeleaf-templates left under src/main/resources/templates. These should be removed.

Digg, and other "myndigheter", will most likely have the possibility to add a link at the bottom of the page pointing at the accessibility report for the site. Let's make a configurable solution where we can give a link to a report under bankid.ui.*.

We should provide audit events for:

• received authentication requests (may be done within the SAML-core lib),
• bad authentication requests (may be done within the SAML-core lib),
• initiated BankID-operations,
• successful BankID-operations,
• failed or cancelled BankID-operations,
• SAML-responses sent back to the SP (may be done within the SAML-core lib)

more?

Make sure everything is ok before we deploy to Maven central

There is only a "Fortsätt"-button but the text says that I should press "Avbryt".

We need to add the configuration below in order to be able to read the texts used in SAML error responses.

Also. Add a Swedish: idp-error-messages file.

spring:
  messages:
    basename: messages,idp-errors/idp-error-messages

https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide

Document how a customized session module should be built

Section 4.2 of Implementation Profile for BankID Identity Providers within the Swedish eID Framework gives requirements for how signing should be performed (userVisible vs. nonVisibleData) etc.

Our implementation should follow this spec.

For those that wish to write their own front-end we need to document the backend API.

Document how to write your own front-end and re-use the javascripts provided.

Depends on #26

Go through ...

Make sure that we have a configured voter for these attributes.

Document Tomcat configuration

• How to get a BankID relying party cert.
• Set up Redis
• Configure supervision
• ...

According to the docs/logging.md documentation.

As mentioned in #19 the context path is hardwired for redirects and api calls in the vue frontend even though it is set in the file bankid-saml-idp/bankid-idp/bankid-idp-frontend/package.json

    "build": "vite build --base=/bankid/idp",

The frontend should be able to resolve the context path from this configuration.

https://www.bankid.com/utvecklare/guider/teknisk-integrationsguide/rp-anvaendarfall

We should have a text for RFA23 and also take action on the new v6 hintCode.

Consider using Typescript instead of Javascript in frontend.

Make accessibility review

Organizations wishing to extend, or change, the backend with additional features should be able to do this by providing their own Spring Boot application that uses/has a dependency to our backend.

• Prepare POM for this
• Document how it is done

Clean upp CSS and apply a "Sweden Connect" look-and-feel.

We need to be able to display also SAML related errors

I think that we need to add some helper texts for scanning the QR-code.

A good example is Kivra - https://accounts.kivra.com/bankid-auth

Also, for accessibility, we should add a frame around the QR-code (can this be done with CSS?)

The current implementation of getting the message to be displayed in the app is constructed upon each poll which is not necessary. Either set the message once upon init or lazy-load it once and set it in context.

According to Sweden Connect specs a sign message may be in HTML. This is not supported by BankID and we should reply with an error in these cases.

Also look into whether we should "clean" markdown messages before sending them to BankID.

We should provide documentation for all configuration settings. Note that many settings are already explained in the scope of the https://github.com/swedenconnect/saml-identity-provider repo.

If an error occurs during the SAML processing, the IdP will attempt to send a error SAML response back. This will not be possible in all cases, for example if the SP (RP) is unknown, or if the signature validation fails. In those cases the user should end up on an error page. Check how implement this in backend/frontend communication.

Currently, there is no way of sending a desired display text in the case authentication using SAML. There is an issue to introduce this kind of extension (swedenconnect/technical-framework#195), but that will be optional. Therefore, we need a way of statically configure a text to be displayed during BankID authentication.

There should be one general default text and each RP configuration should have the possibility to override this default.

Define actuator endpoints:

• health: Verifies that the system is up
  • Valid SAML metadata for all the configured clients
  • RP-certificate for all configured clients are still valid (warn when about to expire)
  • BankID API server is up
• statistics
• audit events (see separate issue about auditlogging)
• more ...

Currently we check the following for which OS/Browser combinations are the most common.
https://analytics.usa.gov/data/
"OS & browser (combined)"

This is strictly not a bad source since it is updated daily but is not representative of Swedish OS/Browser usages towards public sector websites, thus, such a source if updated daily should be preferred over the current one.

The current implementation does not allow time to live to be configured and is always 5 minutes.

• Make sure CSS is overridable
• Use CSS variables for the most common things organizations might want to change
• Add slots for messages to be inserted in
• Make some strings overridable, like the copyright notice?

In some browser/device combination the browser will refresh the webpage upon returning to the browser from the BankId application. If a poll is actively being processed then another one can be executed simultaneously, see diagram.

Racecondition

sequenceDiagram
    User->>BankIdIDP: Poll [1];
    User->>User: Enter Pin and Accept;
    User->>User: Browser Refresh;
    Note right of User: We lose track of [1] here <br> since it belongs to the old browser context <br> but it continues to be executed server side
    BankIdIDP ->> BankIdApi: /collect [1];
    User->>BankIdIDP: Poll [2];
    Note right of BankIdIDP: The initial poll has not been completed <br> Thus collect will be attempted again
    BankIdApi ->> BankIdIDP: OK {Complete} [1];
    Note right of BankIdApi: Once an order has been completed <br> it can not be collected again

    BankIdIDP ->> BankIdApi: /collect [2];
    BankIdApi ->> BankIdIDP: ERROR {No such Order} [2];
    BankIdIDP ->> User: ERROR {No such Order} [2];
    

This problem can be fixed by not allowing multiple non-idempotent calls by using distributed locks.
E.g. Redisson https://github.com/redisson/redisson/wiki/8.-Distributed-locks-and-synchronizers

If the same user sends more than one of the same request in parallel the api shall respond with a 429 and ask the client (javascript) to try again later by using a retry-after header.

https://www.rfc-editor.org/rfc/rfc6585#section-4

A description of the error shall be given in JSON

Make sample for how we deploy BankID IdP to Sweden Connect Sandbox

Include scripts, configuration, Docker file and documentation.

We need to put together test specifications for manual tests.

According to the Swedish eID Framework a sign service may send an AuthnRequest that does not include a SignMessage extension. In these cases we must still invoke the BankID Signing, but need a text to sign and display. Let's introduce a default sign text to use (possibly per RP).

As it is implemented now it looks for display name in Organization. It should use Saml2ServiceProviderUiInfo from https://github.com/swedenconnect/saml-identity-provider.