Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Richiedere differenti "AttributeConsumingService" in base alla decisione del client #56

Open
ebusi opened this issue Sep 22, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@ebusi
Copy link
Contributor

ebusi commented Sep 22, 2022

Ciao. Sto lavorando ad un progetto per un proxy OIDC e/o SAML verso gli IDP Spid (quindi backend SAML) ed ho preso il vostro progetto come traccia.
Avrei l'esigenza che i client che contattano i frontend possano richiedere più o meno attributi dell'utente (visto che per i privati alcune informazioni rilasciate dagli idp sono gratuite ed altre no).

Ho letto la documentazione di SATOSA. In alcuni punti è un po' lacunosa quindi mi sono guardato anche il codice di SATOSA e delle sue dipendenze. Non definirei Python il mio linguaggio di punta ma penso di aver capito grosso modo quanto letto e non ho trovato un modo per risolvere la mia esigenza. Quindi ho optato per estendere le funzionalità del vostro spidSaml2 backend.

La mia idea era quindi di definire un mapping tra richiesta arrivata al frontend e Authn request che poi parte dal backend SAML.
Nel concreto stavo pensando di:

  • definire nel backend multipli AttributeConsumingService, ad esempio uno "base" e uno "full". Questa parte dovrei aver capito come farla customizzando un po' il file di configurazione del backend (questo tra l'altro dovrebbe anche permettere di configurare gli ACS per eidas, quelli con index 99 e 100 che al momento sono hardcoded);
  • prevedere degli scope e ACS nei frontend, ad esempio per OIDC "profile" e "full_profile", per SAML "base" e "full";
  • ora dovrei in qualche modo nel metodo authn_request del spidsaml2.py capire cosa mi è arrivato in ingresso e (probabilmente passando sempre dal file di configurazione del backend) prevedere un mapping del tipo
[...]
attribute_mapping:
    OIDC:
        # <backend> : <frontend>
        'profile': 'base' (o invece di profile solo '' o default per definire il mapping predefinito ed essere coerente con altri tipi di configurazioni che ho visto in SATOSA)
        'full_profile': 'full'
    SAML:
        'base': 'base'
        'full': 'full'

Secondo voi ha senso? Oppure esiste già qualche feature che mi è sfuggita che risolve una parte e/o tutti i miei problemi?
Per le modifiche che invece vi sembrano sensate potrei anche prevedere una PR invece.

@MdreW
Copy link
Collaborator

MdreW commented Nov 14, 2022

Ciao @ebusi , perdonami ma non mi era arrivata nessuna notifica della issue.
Non so se sei andato avanti, ma provo ugualmente a risponderti.

Quello che dici ha senso, puoi modificare il consuming service in base ad un attributo.
Prova a dare un occhiata ai microservice

@ebusi
Copy link
Contributor Author

ebusi commented Nov 17, 2022

Ciao, grazie per la risposta.
Sì effettivamente penso che un microservice ad hoc potrebbe gestire la parte di mapping partendo da un file di configurazione simile a quello nell'esempio sopra.
Al momento avevo messo tutto nel backend spid ma usare un microservice è di sicuro la soluzione più pulita

@MdreW
Copy link
Collaborator

MdreW commented Nov 17, 2022

Se ci riesci a lavorarci fai una pull request, potrebbe fare comodo a molti!

@peppelinux peppelinux added the enhancement New feature or request label Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants