Din fremforge-konto

En fremforge-konto er din personlige identitet på platformen. En organisation er en tenant, der faktureres, et arbejdsområde, hvor repositories, medlemmer, secrets, CI-kørsler og politikker hører hjemme. De to er bevidst adskilte begreber, og denne side forklarer, hvad der ligger hvor, hvordan de spiller sammen, og hvordan du fjerner hver af dem.

Én konto, mange organisationer

Du opretter dig én gang. Du får én personlig konto på frem.sh/<your-username> med din e-mail, dine SSH-nøgler, dine personlige adgangstokens, din tofaktorgodkendelse og din lokale adgangskode (hvis du har sat en). Overalt, hvor du godkendes mod fremforge, i brugerfladen, i Git og i API’et, godkendes du som den konto.

Medlemskab af en organisation er en separat relation. Din ene konto kan være medlem af nul, én eller mange organisationer. Hver organisation betaler sin egen bruger for dig. Du ser de organisationer, du tilhører, i brugerfladens organisationsvælger.

To konsekvenser, der er værd at have i baghovedet:

• Når du fjernes fra en organisation, slettes din konto ikke. Organisationens administratorer kan til enhver tid fjerne dig fra deres organisation; det tilbagekalder din adgang til deres repositories og fjerner en betalt bruger fra deres antal, men din personlige konto består, og du kan blive medlem af andre organisationer.
• Når du sletter din konto, slettes de organisationer, du tilhører, ikke. Er du eneste ejer af en organisation, kræver platformen, at du enten udpeger en anden ejer eller opsiger organisationen helt, før din anmodning om sletning af kontoen kan gennemføres.

Medlem af en organisation mere

Du kan være stiftende administrator af mere end én fremforge-organisation uden at oprette flere konti. To tilfælde:

• Samme e-mail, ny tilmelding. Opretter du en ny organisation på frem.sh/_app/signup med en e-mail, der allerede har en fremforge-konto, opdager tilmeldingen den eksisterende bruger, genbruger den og tilføjer dig som ejer (Owner) af den nye organisation. Du får ikke en ekstra adgangskode — dine eksisterende loginoplysninger virker til begge organisationer, og knappen i velkomstmailen hedder “Åbn <slug> →” (log ind med din eksisterende adgangskode) i stedet for det engangslink “Log ind på fremforge →”, som en helt ny administrator får. (Ingen velkomstmail fra fremforge indeholder nogensinde en adgangskode.)
• Inviteret til en eksisterende organisation. Inviterer en anden administrator din e-mail, accepterer du invitationen fra frem.sh/user/notifications, og du bliver tilføjet som medlem af deres organisation. Ingen ekstra konto, ingen ekstra adgangskode.

Hver organisation har sit eget faktureringsforhold til fremverk, sit eget antal brugere, sit eget Mollie-mandat, sine egne fakturaer og sin egen administrationsflade på frem.sh/<slug>/_admin/billing. Der findes ingen samlet regning på tværs af organisationer.

Skift mellem organisationer

Der er ingen organisationsvælger i selve produktet på frem.sh/_app; administrationsfladen for hver tenant styres af sluggen i URL-stien (/<slug>/_admin/...). Den naturlige vælger ligger på Forgejo-siden på frem.sh:

1. Log ind på frem.sh/user/login (eller klik på “Sign in” et vilkårligt sted på marketingsitet, som sender dig gennem frem.sh/_app/login for at finde din organisation ud fra e-mail-domænet — se Sådan fungerer login).
2. Dit dashboard viser alle de organisationer, du tilhører. Klik dig ind i en af dem for at gå i gang med repositories, issues, CI og indstillinger.
3. For at åbne fremforge-administrationen (fakturering, SSO, medlemmer) for en bestemt organisation går du til frem.sh/<slug>/_admin/billing. Det mest almindelige er at lægge et bogmærke til administrations-URL’en for hver organisation, du administrerer.

Sessionsbinding pr. organisation er slået til som standard for alle tenants. Første gang du åbner en organisations administrationsflade, sender fremforge dig gennem en login-runde for den organisation og gemmer en registrering af det pr. organisation i op til 8 timer. Hvad den runde beviser, afhænger af niveauet nedenfor. Med blød binding beviser den, at din browser har et gyldigt login, ikke at du lige har logget ind igen. Kun hård binding får dig til at godkende dig igen.

Målet for runden er Forgejos fælles login på frem.sh/user/login, ikke en SSO-URL pr. organisation. Det er bevidst: det fælles login accepterer både alle forbundne SSO-knapper og lokal adgangskode + tofaktorgodkendelse, hvilket bevarer vejen for SSO-nødadgang. Kan din IdP ikke nås, kan en organisationsejer med lokale loginoplysninger og tofaktorgodkendelse stadig godkende sig, komme igennem bindingskontrollen for organisationen og nå organisationens administration. At sende brugeren gennem en SSO-URL pr. organisation ville skabe et enkelt fejlpunkt (organisationens IdP), som nødadgangen netop er designet til at undgå.

To styrkeniveauer afhængigt af, hvordan din IdP er forbundet:

• Blød binding (standard, nødadgang med lokale loginoplysninger bevaret): en registrering pr. organisation af, hvem der har brugt hver organisations administrationsflade og hvornår, og en runde gennem Forgejo ved første adgang til hver organisation. Er din Forgejo-session aktuel, er runden usynlig og beder ikke om noget: den beviser, at du har sessionen, ikke at du lige er blevet godkendt. Er sessionen ikke aktuel, logger du ind igen. Målet er frem.sh/user/login, som accepterer lokal adgangskode + tofaktorgodkendelse, så et IdP-nedbrud ikke låser organisationens ejere ude.
• Hård binding (regulerede arbejdsbelastninger): tvungen ny attestering fra IdP’en pr. organisation via OIDC prompt=login. Runden bliver en rigtig IdP-attesteret godkendelse afgrænset til den organisation, IdP’en SKAL bede om loginoplysninger og MFA igen, og vores callback kontrollerer, at auth_time ligger inden for de seneste 5 minutter. Sættes op ved at registrere en ekstra OIDC-klient i din IdP ved siden af Forgejo-klienten (samme issuer, separat client_id + client_secret) og indsætte oplysningerne under organisationsadministration → SSO.

Begge niveauer bevarer vejen for SSO-nødadgang: organisationsejere med lokal adgangskode + tofaktorgodkendelse kan komme sig efter ethvert IdP-nedbrud. Hård binding tvinger kun en ny IdP-godkendelse, mens organisationens IdP kan nås. Kan din IdP ikke nås, virker din eksisterende nødadgangsprocedure stadig.

SSO på tværs af flere organisationer

Hver organisation forbinder sin egen IdP under Administration → SSO. Brugere logger ind i en bestemt organisation via organisationens <auth-source-name>-knap på frem.sh/user/login?redirect_to=/<slug> (eller via opslagsflowet på frem.sh/_app/login, som sender dig til den rigtige organisations loginside ud fra domænet i din e-mail).

Er du medlem af to organisationer, der bruger forskellige IdP’er, godkendes du via den IdP, du kommer ind igennem; når din Forgejo-session er etableret, virker navigationen på tværs af organisationer som beskrevet ovenfor. Bruger begge organisationer den samme IdP (f.eks. to forretningsenheder på den samme Authentik-tenant), bringer én godkendelse dig ind i begge.

Første adgang på tværs af organisationer sender dig én runde. Hvor runden går hen, afhænger af, om organisationen har sat hård binding op (en OIDC-klient til step-up):

• Organisation med hård binding: runden går til frem.sh/<slug>/_admin/-/stepup, som starter en OIDC-godkendelsesanmodning med prompt=login mod organisationens step-up-klient. Din IdP beder om loginoplysninger og MFA igen, callbacken kontrollerer ID-tokenet + at auth_time er frisk, og du lander på den oprindelige URL med en ny sessionsregistrering for organisationen.
• Organisation med blød binding: runden går til frem.sh/user/login. Forgejos fælles login viser de godkendelseskilder, der er tilgængelige, altid lokal adgangskode + tofaktorgodkendelse, plus organisationens SSO-knap, når den er forbundet. Er din eksisterende Forgejo-session frisk, følger siden blot redirect_to uden at spørge igen.

Begge niveauer lader nødadgangen med lokale loginoplysninger være intakt. En organisationsejer med lokal adgangskode + tofaktorgodkendelse på Forgejos fælles login kan komme sig efter ethvert IdP-nedbrud; bindingen pr. organisation ændrer ikke den aftale.

Data på kontoniveau og på organisationsniveau

Dette er skillelinjen, der afgør, hvem der kontrollerer hvad efter GDPR, og hvor du skal lede efter hvilken indstilling.

Data på kontoniveau er omfattet af privatlivspolitikken for produktet, hvor fremverk ApS er dataansvarlig. Indhold på organisationsniveau er omfattet af databehandleraftalen, hvor din organisation er dataansvarlig, og fremverk er databehandler på dens vegne.

Oversigt over kontoindstillinger

frem.sh/user/settings er fladen for personlige indstillinger, og den vises af Forgejo. De relevante undersider:

• Profile: navn, e-mail, avatar, foretrukket sprog.
• Security & sign-in: lokal adgangskode, tofaktorgodkendelse, gendannelseskoder, sletning af kontoen. Se Tofaktorgodkendelse.
• SSH keys og GPG keys: offentlige nøgler til Git-handlinger og signering af commits.
• Git-adgangstokens: personlige adgangstokens (PAT’er). OAuth-applikationer, du har givet adgang, vises og tilbagekaldes på frem.sh/user/settings/applications, som ikke har noget punkt i indstillingsmenuen.
• Notifications: præferencer for notifikationer på e-mail og i appen.

Via REST API

En håndfuld handlinger på kontoniveau findes også i det offentlige REST API — nyttigt, når du scripter opstarten af CI, kontrollerer hvilke organisationer et token kan handle på, eller roterer PAT’er fra en automatisering.

• Læs din profil + dine organisationsmedlemskaber GET /_app/api/v1/users/me
• Udsted et personligt adgangstoken POST /_app/api/v1/auth/tokens
• Vis dine aktive tokens GET /_app/api/v1/auth/tokens
• Tilbagekald et token DELETE /_app/api/v1/auth/tokens/:tokenId

Godkend med et personligt adgangstoken (PAT) som Authorization: Bearer ${FREMFORGE_PAT}. For at udstede et nyt PAT skal du have en aktiv login-session i administrationsbrugerfladen; det udstedte tokens omfang kan ikke overstige din rolle.

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  https://frem.sh/_app/api/v1/users/me

Se referencen til det offentlige REST API for den fulde OpenAPI-specifikation.

Fladerne for den personlige konto ovenfor (SSH-nøgler, GPG-nøgler, tilmelding til tofaktorgodkendelse, sletning af kontoen) findes bevidst ikke i det offentlige REST API — det er handlinger med personlige loginoplysninger, som af sikkerhedshensyn kræver en browser med en aktiv login-session.

Sletning af din fremforge-konto (GDPR-retten til sletning)

Efter GDPR art. 17 har du ret til at få dine personoplysninger slettet, med begrænsede undtagelser for lovpligtig opbevaring. fremverk ApS understøtter den ret som dataansvarlig for dine kontodata.

Hvad du selv kan slette

Brugerindstillinger → Sikkerhed og login → Delete account. Selvbetjent sletning:

1. Fjerner dig fra alle organisationer, du i øjeblikket er medlem af. Hver berørt organisations antal brugere reduceres ved næste faktureringsperiode.
2. Reserverer dit brugernavn som slettet, så det ikke kan registreres igen (det forhindrer, at nogen udgiver sig for dig i forhold til historiske commits og poster i revisionsloggen).
3. Sletter dine personlige kontodata endegyldigt: profil, SSH-nøgler, GPG-nøgler, PAT’er, tofaktorhemmelighed, hashes af gendannelseskoder og notifikationspræferencer. Inden for 30 dage; sletning fra backup inden for yderligere 30 dage i henhold til databehandleraftalens §9.
4. Bevarer dine historiske bidrag: forfatterangivelse på commits, forfatterskab af issues og pull requests, kommentarer og poster i revisionsloggen, der nævner dig. At fjerne dem ville ødelægge alle organisationer, der bruger de registreringer som dokumentation for, hvem der gjorde hvad. Dit brugernavn vises som <deleted-account> i den levende brugerflade, mens den underliggende reference til bruger-id’et (et stabilt heltal) holder revisions- og Git-historikken intakt.

Hvad der kræver support

To tilfælde kræver handling via compliance@frem.sh:

• Du er eneste ejer af en organisation. Selvbetjent sletning er blokeret. Udpeg enten en anden ejer via organisationsadministration → Medlemmer og slet derefter din konto, eller skriv til compliance@frem.sh og bed om at få organisationen og kontoen slettet samtidig.
• Du vil have historiske bidrag aktivt omskrevet. Standarden er at bevare forfatterangivelsen under et reserveret, slettet brugernavn. Har du et dokumenteret retsgrundlag for en mere vidtgående sletning (f.eks. et endeligt navneskifte, der fremgår af retsdokumenter), så skriv til compliance@frem.sh med grundlaget. Hver anmodning vurderes individuelt ud fra begrænsningerne i GDPR art. 17, stk. 3.

Hvad vi ikke sletter på anmodning

I henhold til GDPR art. 17, stk. 3, kan følgende opbevares efter sletning af kontoen:

• Fakturerings- og fakturaoplysninger for organisationer, du var tilknyttet, opbevaret i 5 år efter bogføringsloven.
• Poster i revisionsloggen om sikkerhed og misbrug, hvor opbevaring er nødvendig for at fastslå, gøre gældende eller forsvare retskrav eller for at overholde en retlig forpligtelse (f.eks. anmeldelser af misbrug efter DSA art. 16, der opbevares i 5 år i henhold til privatlivspolitikkens §6).
• Samlede, anonymiserede driftsmålinger, som ikke kan identificere dig og falder uden for GDPR’s begreb om personoplysninger.

Bekræftelse før sletning

Sletning af kontoen er destruktiv og kan ikke fortrydes. Det selvbetjente flow kræver, at du godkender dig igen (lokal adgangskode, eller et step-up hos IdP’en, hvis du kun bruger SSO), og at du bekræfter ved at skrive dit brugernavn, det samme Forgejo-mønster, som bruges ved sletning af et repository. Der sendes en bekræftelsesmail, når du indsender anmodningen, og igen, når perioden for sletning fra backup er afsluttet.

Genaktivering

Når sletningen er gennemført, kan kontoen ikke genaktiveres. Brugernavnet er reserveret til det slettede bruger-id for at beskytte historisk forfatterangivelse, så du kan ikke registrere det samme brugernavn igen ved en ny tilmelding. Har du brug for fremforge igen, så tilmeld dig med en ny e-mail og et andet brugernavn.

Krydshenvisninger

• Medlemmer og teams: administration af medlemskab i organisationen fra organisationsadministrationens side
• Tofaktorgodkendelse: opsætning og gendannelse af tofaktorgodkendelse på kontoniveau
• Organisationsadministration: fladen for indstillinger på organisationsniveau
• Forbindelse: SSH-værtsnøgler, kontrol af fingeraftryk, reserveløsning via port 443
• Privatlivspolitik for produktet: retsgrundlaget for behandling af kontodata og de registreredes rettigheder efter GDPR