> For the complete documentation index, see [llms.txt](https://docs.fortifiedid.se/access/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fortifiedid.se/access/common-use-cases/common-use-cases-swe.md).

# Common use cases (SWE)

Vanliga användningsfall för Fortified ID Access.

Den här sidan är till för att göra det lättare att relatera till vad Fortified ID Access kan användas till i praktiken.

## Exempelscenarier

[Konsolidering av data från flera källor till token eller biljett](#konsolidering-av-data-fran-flera-kallor-till-token-eller-biljett) | [ServiceNow med svenska e-legitimationer](#servicenow-med-svenska-e-legitimationer)\
[E-legitimation utan extra mellanhänder](#e-legitimation-utan-extra-mellanhander) | [Autentisering med organisationsägd e-legitimation](#autentisering-med-organisationsagd-e-legitimation)\
[SITHS-autentisering med Fortified ID Access](#siths-autentisering-med-fortified-id-access) | [Säker identifiering på delade enheter](#saker-identifiering-pa-delade-enheter)\
[ADFS med Fortified ID Access](#adfs-med-fortified-id-access) | [Anslutning till federationer som Skolfederation, SAMBI, SWAMID, eIDAS och Feide samt tjänster som DNP](#anslutning-till-federationer-som-skolfederation-sambi-swamid-eidas-och-feide-samt-tjanster-som-dnp) | [Anpassad inloggning för kommunens olika målgrupper](#anpassad-inloggning-for-kommunens-olika-malgrupper) | [Inför passkeys utan att bygga om befintliga lösningar](#infor-passkeys-utan-att-bygga-om-befintliga-losningar)

### Konsolidering av data från flera källor till token eller biljett

**Användningsfall**\
Organisationer behöver ofta inkludera identitets- och behörighetsdata från mer än en källa när en användare autentiseras. Det kan till exempel handla om att hämta grundidentitet från `Active Directory`, komplettera med roll- eller verksamhetsinformation från en `SQL`-databas och sedan använda den samlade datan i en token eller biljett som skickas vidare till en applikation. Ett annat exempel är att hämta identitetsdata från `Active Directory` och därefter berika den med information från en extern webbtjänst, till exempel `Skatteverket Navet/SPAR`, innan rätt attribut och claims inkluderas i den utgående identitetsbäraren. Genom att konsolidera data vid inloggning kan organisationer säkerställa att rätt information följer med utan att behöva bygga kundspecifika integrationer eller plugins.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` kan stödja detta genom konfiguration av autentiseringsflöden, datainsamling och attributhantering där information hämtas från flera källor, normaliseras och sammanställs innan den används i utgående token eller biljett. Med konfigurerbara moduler, `Pipes` och exports kan data bearbetas och återanvändas genom flödet, så att rätt värden inkluderas i exempelvis en `SAML`-assertion, en `OIDC`-token eller annan protokollburen identitetsinformation. Det gör det möjligt att anpassa innehållet i utgående identitetsbärare via konfiguration, till exempel för scenarier som `Active Directory + SQL` eller `Active Directory + extern webbtjänst`, utan att utveckla separata plugins.

### ServiceNow med svenska e-legitimationer

**Användningsfall**\
Organisationer behöver ofta ge användare säker åtkomst till `ServiceNow` eller andra verksamhetssystem utan att vara beroende av traditionella lösenord. Genom att använda `BankID` eller `Freja eID+` som inloggningsmetod kan man erbjuda en välkänd och stark autentisering som fungerar för många olika typer av verksamheter, samtidigt som man minskar administrationen kring lösenord och separata inloggningsrutiner.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` kan stödja detta genom att exponera `BankID` och `Freja eID+` som valbara autentiseringsmetoder vid inloggning till anslutna applikationer via exempelvis `OIDC` eller `SAML`. Lösningen kan koppla användarens e-legitimation till ett befintligt konto i organisationens katalog, till exempel `Active Directory`, och därefter leverera rätt identitet vidare till målplattformen. Det gör det möjligt att införa stark inloggning till `ServiceNow` eller andra verksamhetssystem genom standardiserad integration och konfiguration i stället för kundspecifik utveckling. För organisationer i offentlig sektor kan samma mönster även kompletteras med stöd för `SITHS`, `EFOS` och `Freja OrgID`, och som ett närliggande exempel erbjuder Fortified ID även `IDombud` som ett eget digitalt identitetskoncept för organisationer som vill ta ännu större kontroll över identitetslivscykeln.

### E-legitimation utan extra mellanhänder

**Användningsfall**\
Många organisationer har redan en etablerad `Identity Provider (IdP)`, men saknar inbyggt stöd för e-legitimationer som exempelvis `BankID`. I sådana situationer behöver man ofta lägga till en extern broker-tjänst eller en separat tredjepartslösning för att möjliggöra e-legitimationsinloggning. Det leder lätt till fler integrationer, fler leverantörer, fler avtal och högre komplexitet i en av organisationens mest kritiska processer, användarnas inloggning.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` kan stödja autentisering med e-legitimationer som `BankID`, `Freja`, `SITHS` och andra eID-lösningar, samtidigt som de integreras i organisationens befintliga identitetsmiljö. Det gör det möjligt att behålla kontroll över autentiseringsflöden, loggning, support och förvaltning utan att vara beroende av en separat eID-broker från en tredje part. Fortified ID kan även tillhandahålla anslutning till utvalda eID-leverantörer, till exempel `BankID`, vilket ger kunden en enklare väg till införande och en samlad kontaktpunkt för teknik, support och avtal. Det gör det möjligt att modernisera autentiseringen stegvis och förenkla förvaltningen av kritiska inloggningsflöden.

### Autentisering med organisationsägd e-legitimation

**Användningsfall**\
Många organisationer behöver stark autentisering utan att vara helt beroende av nationella e-legitimationer som `BankID` eller `Freja eID+`. Det blir särskilt viktigt när organisationen behöver full kontroll över utfärdande, administration och revokering, eller när anställda, konsulter, partners eller internationella användare inte kan förväntas använda en personlig nationell e-legitimation i arbetet.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` kan stödja autentisering med organisationsägda e-legitimationer tillsammans med mer traditionella autentiseringsmetoder, och kan upprätthålla de autentiseringspolicys och tillitsnivåkrav som behövs för skyddade applikationer och resurser. Ett praktiskt exempel är `IDombud`, som Fortified ID presenterar som en digital identitetstjänst byggd på moderna plånboksbaserade identitetsmodeller. Det ger organisationer ett sätt att kombinera stark autentisering med större kontroll över identitetslivscykeln, samtidigt som inloggningen integreras via `Access`. Läs mer om `IDombud`: [idombud.se](https://idombud.se/).

### SITHS-autentisering med Fortified ID Access

**Användningsfall**\
`SITHS` används inom regioner, kommuner, privata vårdgivare och myndigheter för säker identifiering, autentisering och elektronisk signering. Samtidigt behöver många organisationer kunna införa `SITHS` i sina befintliga identitetsmiljöer på ett sätt som är säkert, användarvänligt och långsiktigt hållbart.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` erbjuder en modern plattform för `SITHS`-autentisering och kan användas både som organisationens primära `Identity Provider (IdP)` och som komplement till befintliga identitetslösningar. Access stödjer flera olika integrationsmönster beroende på behov, till exempel som `IdP` eller `OpenID Provider (OP)` med inbyggt stöd för `SITHS`, som broker eller `IdP`-proxy mot `Inera`, genom `mTLS`-baserad autentisering med klientcertifikat, eller i kombination med befintliga plattformar som `ADFS`. Access kan också berika identiteten med information från flera datakällor, som `HSA`, `Active Directory`, `Entra ID`, `SQL` och andra verksamhetssystem. Det gör det möjligt att införa `SITHS` på det sätt som passar verksamheten bäst, oavsett om målet är att modernisera en befintlig lösning eller att samla autentisering och federation i en gemensam plattform.

### Säker identifiering på delade enheter

**Användningsfall**\
Delade datorer och mobila enheter är vanliga i kommuner, regioner och andra verksamheter där flera medarbetare använder samma utrustning under en arbetsdag. Inom vård, omsorg och skola ställer detta höga krav på säker identifiering och spårbarhet, eftersom flera personer behöver kunna använda samma enhet utan att identiteter, behörigheter eller sessioner blandas samman.

**Hur det mappar till Fortified ID**\
Fortified ID kan stödja detta genom `IDombud`, där varje användare har sin egen personliga digitala identitet skyddad av en personlig `PIN`-kod. Det gör det möjligt att använda flera användarprofiler på samma delade enhet, samtidigt som varje profil är skyddad och endast tillgänglig för den användare som äger identiteten. På så sätt kan organisationer uppnå stark identifiering, tydlig spårbarhet och säkrare användning av delade enheter utan att behöva ge varje användare en egen fysisk enhet. Läs mer om `IDombud`: [idombud.se](https://idombud.se/).

### ADFS med Fortified ID Access

**Användningsfall**\
Många organisationer använder fortfarande `ADFS` som en central del av sin identitets- och åtkomstmiljö. Samtidigt ökar behovet av att stödja fler e-legitimationer, starkare autentisering och mer flexibla identitetsflöden än vad `ADFS` ensam är byggd för att hantera på ett enkelt sätt. För många är det därför inte bara en fråga om att ersätta `ADFS`, utan om hur den befintliga lösningen kan kompletteras stegvis utan att skapa onödig komplexitet.

**Hur det mappar till Fortified ID**\
Fortified ID `Access` kan komplettera `ADFS` på flera olika sätt beroende på behov och målbild. Exempel:

* **eID-lager** - Access kan fungera som ett eID- och autentiseringslager ovanpå `ADFS`, där organisationen får stöd för exempelvis `BankID`, `Freja`, `SITHS` och `EFOS` utan att behöva bygga separata integrationer mot varje leverantör.
* **Starkare autentisering** - Access kan användas för att införa starkare autentisering, till exempel `MFA`, eller för att lägga till stöd för specifika scenarier som `SITHS` mot `ADFS`.
* **Tillitssignalering** - Fortified ID kan användas för att addera tillitssignalering till `ADFS` i scenarier där `ADFS` ingår i en federation med sådana krav, till exempel vid anslutning till federationer som `SWAMID`, `SAMBI` eller `Feide`.

Detta gör det möjligt att modernisera identitetsmiljön stegvis, minska komplexiteten och samtidigt fortsätta använda `ADFS` där det fortfarande fyller en viktig funktion.

För vidare exempel, se:

* [Microsoft ADFS | Fortified ID](https://www.fortifiedid.se/losningar/adfs)
* [On-premise MFA för högskolans ADFS ansluts till SWAMID](https://www.fortifiedid.se/post/on-premise-mfa-f%C3%B6r-h%C3%B6gskolans-adfs-ansluts-till-swamid)
* [SITHS eID för Active Directory Federation Services (ADFS)](https://www.fortifiedid.se/post/siths-eid-for-active-directory-federation-services-adfs)
* [How to mark primary authentication Fortified ID ADFS adapters as MFA](https://docs.fortifiedid.se/solutions/active-directory-federation-services-adfs/access-policies/how-to-mark-primary-authentication-fortified-id-adfs-adapters-as-mfa)

### Anslutning till federationer som Skolfederation, SAMBI, SWAMID, eIDAS och Feide samt tjänster som DNP

**Användningsfall**\
Många organisationer använder tjänster och applikationer som bygger på federativ inloggning via svenska eller europeiska federationer. Exempel på federationer är:

* `Skolfederation` för grund- och gymnasieskola.
* `SAMBI` för vård och omsorg.
* `SWAMID` för högskola och universitet.
* `eIDAS` för gränsöverskridande inloggning mellan svenska och utländska tjänster.
* `Feide` som ett motsvarande exempel i Norge.

För att en organisation ska kunna ansluta till sådana federationer behöver den uppfylla tekniska krav på kompatibilitet, tillitsnivåer, säkerhet och regelefterlevnad. Utöver detta kan enskilda tjänster ställa krav på inloggning med en metod på en viss tillitsnivå. Ett exempel är Digitala nationella prov (DNP), där lärare behöver logga in med en metod på tillitsnivå 3 eller högre.

**Hur det mappar till Fortified ID**\
Fortified ID Access kan användas som en fristående `Identity Provider (IdP)` eller som en del av en eller flera federationer. Som fristående IdP hanterar Access säker autentisering för organisationens egna applikationer. Genom federationer kan samma identitet även användas mot externa tjänster och samarbetspartners, samtidigt som organisationen behåller kontroll över autentisering, säkerhet och användarinformation.

I en federation litar flera parter på gemensamma regler för identitet, autentisering, tillitsnivåer och attribut. En aggregerad federation samlar flera anslutna parter och tjänster bakom en gemensam federationsmodell, vilket gör att organisationen kan ansluta till många tjänster utan att bygga separata inloggningslösningar för varje integration.

Fortified ID Access har stöd för anslutning till dessa federationer med hög flexibilitet kring inloggningsmetoder, tillitssignalering, attributhantering samt bibehållen säkerhet och regelefterlevnad. Access kan också hantera krav på starkare inloggning och högre tillitsnivåer, till exempel LoA3 eller LoA4, för tjänster och applikationer som ställer sådana krav.

### Anpassad inloggning för kommunens olika målgrupper

**Användningsfall**\
En kommun har ofta många olika målgrupper som behöver åtkomst till olika typer av tjänster och applikationer. Det kan till exempel handla om:

* lärare och elever som behöver komma åt skolans digitala tjänster.
* omsorgspersonal som behöver åtkomst till patientjournaler.
* medborgare som använder kommunens e-tjänster för exempelvis bygglov eller avfallshantering.
* anställda som behöver logga in i interna system.

Dessa målgrupper har olika förutsättningar och olika krav på identiteter, inloggningsmetoder och säkerhetsnivåer. Exempelvis kan omsorgspersonal behöva använda en godkänd metod som SITHS för åtkomst till patientjournaler, medan medborgare använder e-legitimation för att nå sina egna tjänster.

**Hur det mappar till Fortified ID**\
Med Fortified ID Access kan kommunen hantera dessa behov i en och samma lösning. Access erbjuder flera olika inloggningsmetoder, stöd för uppslag mot olika identitetskällor som Active Directory, Google, Entra ID, Skatteverket och HSA, samt stöd för olika enhetstyper som PC, Mac, Chromebook, iPhone och Android. Det flexibla men samtidigt lättanvända konfigurationsverktyget gör det möjligt att skapa olika inloggningsflöden för olika målgrupper och scenarier. Det kan till exempel vara SITHS-inloggning med uppslag mot HSA för omsorgspersonal som behöver åtkomst till patientjournaler, eller inloggning med engångskod för lärare som ska nå en tjänst via Skolfederationen.

### Inför passkeys utan att bygga om befintliga lösningar

**Användningsfall**\
Många organisationer vill införa en säkrare och enklare inloggning än lösenord, utan att skapa friktion för användarna eller behöva byta ut stora delar av sin befintliga identitetsmiljö. Passkeys, baserade på FIDO-standarden, är en stark kandidat eftersom de är phishing-resistenta, användarvänliga och kan ge en lösenordsfri inloggningsupplevelse. Samtidigt är det sällan så enkelt som att bara ge användaren en passkey och sedan vara klar. Alla applikationer, tjänster, identitetsplattformar och enheter har inte stöd för FIDO på samma sätt, och många organisationer är redan beroende av befintlig federation, SAML, OIDC, katalogtjänster, onboardingflöden och styrande säkerhetspolicys. Utmaningen blir därför inte bara att införa passkeys, utan att göra det på ett sätt där befintlig infrastruktur kan återanvändas och där samma starka inloggning kan komma fler tjänster till del.

**Hur det mappar till Fortified ID**\
**Fortified ID Access** hanterar autentiseringen. Access gör det möjligt att införa passkeys stegvis och använda dem som inloggningsmetod även i miljöer där alla målapplikationer inte är FIDO-anpassade. Genom att låta Access fungera som autentiseringslager kan organisationen brygga passkeys mot befintlig federation, SAML, OIDC och andra identitetsflöden i stället för att bygga om varje ansluten tjänst separat. Det innebär att användaren kan få en modern, phishing-resistent inloggning samtidigt som organisationen behåller sina befintliga integrationer, policys och identitetskällor.

**Fortified ID Enrollment** hanterar registreringen av passkeys. Enrollment ger stöd för registrering genom både självservice och delegerade processer. Det gör att registreringen kan anpassas till verksamhetens krav, till exempel genom att skyddas med starkare metoder med hög tillit som SITHS, EFOS eller andra e-legitimationer, eller genom att utföras av helpdesk, administratör eller annan utpekad roll vid onboarding och support. I miljöer där Microsoft Entra ingår kan Fortified ID också användas som det kontrollerade workflow-lagret kring passkey-aktivering, så att organisationen får en mer flexibel och styrd registreringsprocess än i enbart standardflöden.

Det här ger flera praktiska fördelar:

* samma passkey-strategi kan användas mot fler applikationer, inte bara de som har inbyggt stöd för passkeys
* befintliga integrationsmönster som SAML, OIDC och federation kan återanvändas
* enrollment kan säkras med högre tillit och anpassas till onboarding-, support- och återställningsprocesser
* verksamheten kan använda både självservice och delegerad hantering beroende på målgrupp och risknivå
* passkeys kan kombineras med andra identitetsmönster i Fortified IDs erbjudande, till exempel IDombud och verifiable credentials, i scenarier där identitetsbevisning, onboarding eller framtida wallet-baserade flöden behöver högre kontroll och integritet

Det gör Fortified ID Access till mer än bara stöd för ännu en autentiseringsmetod. Det blir ett sätt att införa passkeys utan att börja om från början, samtidigt som man behåller de säkerhetsmässiga fördelarna med FIDO såsom phishing-resistens, stark identitetskoppling och en enklare användarupplevelse.

För organisationer som vill införa en säker digital identitet för inloggning, där organisationen själv äger och utfärdar identiteten, kan [digital tjänstelegitimation](/access/readme/digital-work-identity/eleg-digital-tjanstelegitimation.md) vara ett relevant nästa steg. Det är en lösning där passkeys används som en del av den tekniska grunden för datorbaserad användning.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.fortifiedid.se/access/common-use-cases/common-use-cases-swe.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.