folkehelseinstituttet / fhi.helseid Goto Github PK

Check the others that they also do the same.

Ved å bruke rollesjekk mot HPR vil det gjøres et kall mot HPR hver gang denne middlewaren blir kjørt.

Dette kan føre til en mye trafikk mot HPR. Det burde være mulig å optimalisere/cache oppslag mot HPR dersom man ønsker det.

Dette kan være en feature man skrur på med IHprFeatureFlags f.eks og en angitt levetid på cache.

HelseID kan tilby informasjon om virksomhet i sikkerhetsbilletter (access tokens). Vi tilbyr to claims: ett for hovedenhet og ett for underenhet, begge inneholder organisasjonsnummer fra enhetsregisteret.

HelseID støtter tre mekanismer for håndtering av organisasjonsnummer og alle tre bør være støttet av fhi.helseid:

1. Organisasjonsnummer kan være lagret i en klientkonfigurasjon. HelseID vil da inkludere disse i access tokens som vi utsteder, klienten kan ikke påvirke om disse inkluderes, klientautentiseringen fungerer her som autentisering av både klient og virksomhet.
2. Organisasjonsnummer kan være lagret i en klientkonfigurasjon, men vi har en liste over gyldige underenheter. Dette fungerer som over, men klienten må fortelle HelseID hvilken underenhet den representerer når den ber om en brukerpålogging eller et token. HelseID vil validere at underenheten finnes i listen over gyldige underenheter (hvitelisten) før et access token utstedes.
3. En liste over gyldige organisasjonsnummer for hovedenheter kan være lagret i klientkonfigurasjonen. Klienten må da fortelle HelseID hvilken hovedenhet og underenhet den representerer når den ber om en brukerpålogging eller et token. HelseID vil validere at hovedenheten er gyldig, men vil stole på informasjon om underenhet uten å validere denne. Listen over gyldige hovedenheter baserer seg på representasjonsforhold for virksomheter som er opprettet i Altinn. Dette mønsteret er tilgjengelig i HelseID sitt testmiljø, men er ikke godkjent for bruk i produksjon ennå.

fhi.helseid bør støtte alle disse mønstrene, både i forbindelse med brukerpålogging og i en maskin-til-maskin kontekst.

Det er mange tilfelle hvor Hpr ikke benyttes. Dette bør da kunne trekkes ut som egen pakke.

Etter det jeg har forstått fra Rune Grimstad, brukes disse bibliotekene for å understøtte lastbalanseringer.
Burde ikke evt. en slik funksjonalitet ligget i et extensionbibliotek?

Denne ble feil oppdatert i PR #316. Feilen stopper publiseringen av neste versjon av Fhi.HelseId.

PR #320 oppdaterer Fhi.HelseId.TestSupport til å referere siste publiserte versjon av Fhi.HelseId. Det er for tiden versjon 5.2.0.

Microsoft mapper om følgende claims fra HelseId:

• "given_name" -> "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
• "family_name" -> "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"

Dette er det tatt høyde for i Web-delen hvor man fjerner denne mappingen:

Dette gjøres ikke for API, så man vil ikke få tak i given_name eller family_name fra claims i et access token om dette innholder det. Her må samme fiks gjøres.

Når man bruker denne komponenten er ikke protected paths beskyttet fra personer med en ikke godkjent HPR-rolle.
F.eks om en app har satt opp tilgang til kun leger på denne måten:

public class HprApprovals : GodkjenteHprKategoriListe
{
    public HprApprovals()
    {
        Add(Kodekonstanter.OId9060Lege);
    }
}

Om man da logger inn med en bruker som er sykepleier får man fortsatt tilgang beskyttede pather, f.eks index.html.
Alle API-kall vil dog gi 403 Forbidden.

Feilen ser ut til å ligge her:

Det blir ikke tatt hensyn til HprKonfigurasjon her.
Dersom UseHpr og UseHprPolicy er true burde policy for protected paths blitt satt til Policies.GodkjentHprKategoriPolicy.

Så lenge UseHprNumber er true brukes Policies.HprNummer uansett for disse pathene.

Får følgende kræsj på grunn av versjonskonflikt mellom transitive referanser. Skjer i prosjekter hvor andre refererte pakker har transitiv referanse til nyere versjon av Microsoft.IdentityModel.Tokens. Ulike versjoner av Microsoft.IdentityModel.Protocols.OpenIdConnect og Microsoft.IdentityModel.Tokens forårsaker kræsjen. Kan løses ved å eksplisitt legge inn referanse til ny versjon av Microsoft.IdentityModel.Protocols.OpenIdConnect, men direkte støtte for dotnet 8 hadde vært å foretrekke.,

Har laget en PR (#316) slik at både dotnet 6 og 8 støttes direkte, men støtte for dotnet 8 påvirker også workflow filene og jeg er usikker på om det er blitt løst riktig.

System.InvalidOperationException: IDX20803: Unable to obtain configuration from: '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.
 ---> System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Json.JsonConvert' from assembly 'Microsoft.IdentityModel.Tokens, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.Microsoft.IdentityModel.Protocols.IConfigurationRetriever<Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfiguration>.GetConfigurationAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
   at Microsoft.IdentityModel.Protocols.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
   --- End of inner exception stack trace ---
   at Microsoft.IdentityModel.Protocols.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
   at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()

See

version 6.0.25 ser ut til å være den riktige.

E.g. Fhi.helseid.testsupport depends on fhi.helseid.

The packagereference should use version "5.*" so that we dont need to update it just because the package have a minor or patch update.

Check the other projects too.

Workflow filene Fhi.HelseId.CI.yml og Fhi.HelseId.Refit.Nuget.yml fører til at det blir bygget 2 ganger. En gang per framework versjon. Dette skyldes bruk av matrix.

See yml here: https://github.com/folkehelseinstituttet/Fhi.ClientCredentials/blob/main/.github/workflows/Fhi.ClientCredentials.Refit.Nuget.yml

Ser at også Fhi.HelseId.Refit.nuget.yml bruker den korrekte metoden.

Fhi.HelseId og Fhi.HelseId.TestSupport bruker den ikke.

Remove the publish job used now, and replace with the corresponding job from the above.

PS: The job used now have a tendency to fail sometimes.

Under .github/workflows

fhi.helseid støtter i dag bare tradisjonelle web-applikasjoner og api-er. Mye av programvaren som brukes i norsk helsesektor er desktopprogrammer (windows) og gjerne delt opp i en klient-server arkitektur der vi har en felles backend som kommuniserer med lokalt installerte klienter.

For å støtte dette scenariet må vi gjøre en stor omskriving av komponenten. Det blir sannsynligvis en egen komponent på siden av de andre, men den bør kunne gjenbruke mye fra den eksisterende. Tenker da særlig på konfigurasjon, men tror vi kan gjenbruke mer.