Impedire il caricamento di due metadata SP con uguale entityID

[alranel]

Se si configurano due metadata SP con lo stesso entityID, l'accettazione della AuthnRequest restituisce un errore.

Bisogna impedire che l'utente possa confondersi, e quindi bisogna prevenire questa situazione restituendo un errore all'avvio del testenv.

[fmarco]

@alranel l'errore è bloccante o solo informativo? Potremmo gestirlo come gli altri errori eventuali all'avvio dell'applicazione, ovvero:

1. carichiamo il metadata corrispondente alla prima occorrenza valida dato un entity id X.
2. le successive n occorrenze di metadata con entity id uguale ad X verranno scartate e l'applicazione ritornerà un errore di qualche tipo

Cosa ne pensi?

[alranel]

Se possibile impedirei l'avviamento del testenv, che direi sia la cosa più semplice anche da implementare e il modo più immediato per far correggere il problema

[bfabio]

@fmarco Are you still working on this? If not, do you mind if I do?

[fmarco]

@bfabio Feel free to work on it 👍

[bfabio]

Thanks @fmarco

[bfabio]

Reopening after the revert in #320.

[peppelinux]

qui

spid-testenv2/testenv/storages.py

Line 233 in efb0854

entity_id = Column(String, primary_key=True, nullable=False)

si potrebbe fare anche uno unique preventivo in caso di db
https://docs.sqlalchemy.org/en/14/core/constraints.html#unique-constraint

... nada, è già primary key!

Ma magari dato che ci siamo invece di body di tipo String facciamo di tipo Text
https://docs.sqlalchemy.org/en/13/core/type_basics.html#generic-types

[peppelinux]

Complessivamente questo comportamento non è ad oggi riscontrabile quando spid-testenv2 carica i metadata da RDBMS, perché entityID è primarykey e quindi unique.

Per quanto riguarda i metadata da file o da locazione remota e considerando il comportamento di altri prodotti SP/IDP SAML2, vedi shibboleth, pysaml2 e altri, questo problema è abbastanza tipico.

I metadata crescono nel tempo e fare controlli di questo genere produrrebbe pericolosi rallentamenti della piattaforma.

Nel caso in cui i metadata crescessero sarebbe consigliabile adottare RDBMS o MDQ, con il primo otteniamo la certezza dell'unicità della chiave primaria, con il secondo la sicurezza del processo di batch di aggregazione.

metadata con entityID uguali producono che alla prima occorrenza riscontrata avviene il break del loop di ricerca, così è su tante altre piattaforme, la validazione basata su file andrebbe condotta da un operatore con una procedura totalmente out-of-band.

Di certo RDBMS e MDQ sono soluzioni generali e ineludibili quando le dimensioni della federazione crescono nel tempo