Ofte stillede spørgsmål om enkeltlogon

Adobe tilbyder følgende identitetstyper:

• Enterprise ID: Organisationen opretter og ejer kontoen. Konti oprettes på et domæne, der er gjort krav på. Adobe administrerer legitimationsoplysninger og behandler login.
• Federated ID: Organisationen opretter og ejer kontoen samt linker med enterprise-kataloget via føderation, mens enterprise-virksomheden eller skolen administrerer legitimationsoplysninger og behandler logon via enkeltlogon.
• Adobe ID: Brugeren opretter og ejer kontoen. Adobe administrerer legitimationsoplysninger og behandler login. Afhængigt af lagringsmodellen ejer brugeren eller organisationen kontoen og aktiverne.
  

Ja, du kan have en blanding af Enterprise ID'er, Federated ID'er og Adobe ID'er, men ikke i samme domæne, der er blevet gjort krav på.

Enterprise ID og Federated ID er eksklusive på domæneniveau. Derfor kan du kun vælge én af dem. Du kan bruge Adobe ID sammen med enten Federated ID eller Enterprise ID.

Eksempel: Hvis der kun gøres krav på ét domæne af en Enterprise-konto, kan it-administratoren vælge enten Enterprise ID eller Federated ID. Hvis en organisation gør krav på flere domæner for et Enterprise-abonnement, kan it-administratoren bruge ét domæne med Adobe ID'er og Enterprise ID'er og et andet domæne med Adobe ID'er og Federated ID'er og så videre. Det betyder, at du for hvert domæne kan have enten Enterprise ID eller Federated ID sammen med Adobe ID.

Styringen af Adobe-licenser med Federated ID er hurtigere, nemmere og sikrere.

• It-administratorer styrer godkendelse og brugerlivscyklus.
• Når en bruger fjernes fra enterprisekataloget, har brugeren ikke længere adgang til computerapps, tjenester og mobilapps.
• Med Federated ID'er kan organisationer udnytte identitetsstyringssystemer, som allerede er i drift.
• Da slutbrugerne benytter organisationens eget identitetsstyringssystem, behøver it-administratoren ikke bruge en separat proces til styring af adgangskoder.

Når slutbrugerne logger på, omdirigeres de til din organisations egen standardiserede og velkendte enkeltlogonproces.

Ja. Du kan skifte fra Enterprise til Federated ID'er ved hjælp af det samme domæne. Du finder flere oplysninger under Flyt domæner på tværs af kataloger.

Ja, du kan føderere dit enterprisekatalog og dets infrastruktur til logon og godkendelse med Adobe ved hjælp af din SAML 2.0-kompatible identitetsudbyder.

Nej. Hvis der gøres krav på et domæne for Federated ID'er, bliver eksisterende Adobe ID'er med e-mailadresser i dette domæne ikke påvirket. Eksisterende Adobe ID'er på Admin Console bevares.

Aktivoverførsel er en automatisk proces. Når du starter denne proces, overføres alt det understøttede indhold, der i øjeblikket er gemt på din Adobe ID-konto, til din Enterprise ID-/Federated ID-konto. Du kan få flere oplysninger i Automatisk aktivoverførsel.

Adobes implementering af Federated ID understøtter autorisation. Godkendelse håndteres af din identitetsudbyder (IdP).

Som enterprise-organisation kan I oprette en sammenkædning mellem jeres godkendelsestjenester (med en id-struktur som f.eks. Active Directory) og Adobes. På den måde kan enterprise-organisationen være vært for godkendelsen. Adobe lagrer aldrig adgangskoder, og it-administratorer kan ikke nulstille adgangskoder eller redigere brugernavne for Federated ID'er via Adobe Admin Console.

Ja, med funktionen Importér brugere, som findes i Adobe Admin Console. Du kan finde flere oplysninger i Tilføjelse af flere brugere.

Nej. Adobe har grænseflader med din identitetsudbyder og ikke direkte til dit virksomhedskatalog. Derimod understøtter vi import af bruger- og gruppeoplysninger fra enterprisekataloget til Adobe Admin Console. Du kan finde flere oplysninger i Tilføjelse af flere brugere.

Adobe anbefaler, at alle virksomhedsadministratorer skifter deres Adobe ID-brugere til Federated ID'er. Du kan overføre fra Adobe ID'er til Federated ID'er ved hjælp af disse trin.

Adobe bruger den sikre og meget udbredte branchestandard Security Assertion Markup Language (SAML). Det betyder, at implementeringen af SSO er nem at integrere med en hvilken som helst identitetsudbyder, der understøtter SAML 2.0.

Her følger en liste over nogle identitetsudbydere, der er SAML 2.0-kompatible:

• Okta
• Oracle Identity Federation
• Microsoft ADFS
• Microsoft Azure AD^#
• Google-føderation^# 
• Ping Federate
• Salesforce IdP med eksternt signeret certifikat
• CA Federation
• ForgeRock OpenAM
• Shibboleth
• NetIQ Access Manager
• OneLogin
• Novell Access Manager

Ja, så længe den følger SAML 2.0-protokollen.

Ja, og identitetsudbyderen skal være SAML 2.0-kompatibel.

Som minimum skal SAML-identitetsudbyderen have:

1. IDP-certifikat
2. Webadresse til IDP-logon
3. IDP-binding: HTTP-POST eller HTTP-Redirect
4. Identitetsudbyderens ACS-webadresse (Assertion Consumer Service), og den skal kunne acceptere SAML-anmodninger og RelayState.

Kontakt din identitetsudbyder, hvis du har yderligere spørgsmål.

Nej. Det er aldrig lykkedes at bryde et 2048-bit-certifikat. De eneste mennesker, som har nogensinde har cracket selv et 768-bit-certifikat (Lenstra-gruppen), har anslået, at det ville have taget dem over 1000 år med den samme hardware at cracke bare et 1024-bit-certifikat (en bedrift, der er ca. 32.000.000 gange lettere end at cracke et 2048-bit-certifikat).

Hvis du gerne vil have de seneste nørdede data, der skønner, hvor lang tid det vil tage at cracke certifikater med forskellige længder, skal du gå til dette websted. Du kan finde et sjovt (præcis, men marketingorienteret) billede af, hvor sikre disse certifikater er, på dette websted (eller dets underliggende matematiske websted).

Nej, denne grænse for certifikater bruges til at kode kommunikationsrøret mellem browseren og serveren. Disse IdP-certifikater bruges derimod til at signere (ikke kode) den data, der sendes gennem det kodede rør. Browseren ser aldrig disse certifikater. De bruges kun mellem Adobe og kundens IdP.

Du kan få gode, kommercielle 2048-bit-certifikater for ca. $10 pr. år i certifikatets levetid. De certifikater, der bruges af identitetsudbydere, kan være selvsigneret, hvilket betyder, at de kan genereres omkostningsfrit med open source-software.

Nej, da der er to andre lag med stærk kryptering, som kontrollerer identitetsudbyderens identitet, og som skal crackes, før man kan give sig ud for at være identitetsudbyderen. Og ingen af disse øvrige lag er selvsigneret. Det betyder, at du ville ikke kun skulle cracke det certifikat, der gennemtvinger krypteringen, men også certifikatet for den underskriver, der har genereret det pågældende certifikat.

Telefonnummer og e-mailadresse til premiumsupport finder du i velkomstmeddelelsen og den vedhæftede PDF-fil, som blev sendt med e-mail til din kontoadministrator.

Det samme webadresseslutpunkt kan bruges til flere kataloger. Føderationsmetadataene administreres dog separat for hver enkelt IdP. Derfor skal de fælles IdP-slutpunkt kunne håndtere anmodninger med forskelligt indhold.

Ja, hvis katalogets SAML-integration anvender brugernavn-formatet, og brugernavnene i Admin Console er identiske med de vedvarende ID'er, der er angivet. Dette kræver dog, at vedvarende id'er skal være tilgængelige på det tidspunkt, hvor brugerne synkroniseres i Admin Console. Dette er ikke et hyppigt scenarie. I praksis understøttes vedvarende format til NameID-elementet derfor ikke.

Nej. Værdien af NameID-elementet anvendes som brugernavn i Admin Console. NameQualifier ignoreres.

Ja. Adobe understøtter SHA256-certifikater. Få flere oplysninger i Konfigurer identitet.

Ja. Du skal give de CA-signerede certifikater til Adobe Kundesupport. Så uploader vi det for dem.

Log ind på Admin Console, gå til Support > Supportoversigt, og klik på Opret sag. Der er flere oplysninger under Sådan opretter og administrerer du supportsager.

Som standard er Okta-certifikaterne selvsignerede. I undtagelsestilfælde (og eventuelt mod betaling) kan de få certifikatet signeret af en offentlig CA i stedet.