Geïsoleerde web-apps

Let op: De eerste release van Isolated Web Apps, en alle API's met een hoge vertrouwensgraad die deze vereisen, zal alleen beschikbaar zijn voor ChromeOS-apparaten die beheerd worden door Chrome Enterprise en voor geselecteerde ontwikkelingspartners. We streven ernaar dit in de toekomst uit te breiden naar meer partners en onbeheerde en platformonafhankelijke apparaten.

Het web is een werkelijk uniek applicatieplatform. Apps die erop gebouwd zijn, zijn direct toegankelijk op elk besturingssysteem zonder dat er code hoeft te worden aangepast of gecompileerd. Wanneer een gebruiker uw app bezoekt, heeft hij of zij altijd de meest recente versie. Ze zijn installeerbaar , werken offline, zijn zeer capabel en super gemakkelijk te delen met slechts een link. Bouw een webapplicatie en hij werkt gewoon, overal.

Omdat het web standaard veilig en beveiligd moet zijn, moet het beveiligingsmodel zeer conservatief zijn. Alle nieuwe functionaliteiten die worden toegevoegd, moeten veilig zijn voor een gewone gebruiker die er per ongeluk via een URL op stuit. We noemen dit beveiligingsmodel het ' drive-by-web' . Hoewel dit voor veel toepassingen prima werkt en de beveiliging kan worden verbeterd met Content Security Policies en cross-origin isolation , is het niet geschikt voor elk gebruiksscenario. Een aantal zeer belangrijke en krachtige API's, zoals Direct Sockets en Controlled Frame , die ontwikkelaars nodig hebben, kunnen niet veilig genoeg worden gemaakt voor het 'drive-by-web'.

Voor deze toepassingen bestaat momenteel geen mogelijkheid om ze op het web te ontwikkelen. Voor anderen is het beveiligingsmodel van het web mogelijk niet conservatief genoeg; ze gaan er wellicht niet van uit dat de server betrouwbaar is en geven de voorkeur aan afzonderlijk geverifieerde en ondertekende, op zichzelf staande applicaties. Er is behoefte aan een nieuw, betrouwbaar beveiligingsmodel. Isolated Web Apps (IWA's) bieden een geïsoleerd, gebundeld, geverifieerd, ondertekend en betrouwbaar applicatiemodel dat bovenop het bestaande webplatform is gebouwd om deze ontwikkelaars in staat te stellen te ontwikkelen.

Een spectrum van vertrouwen op het web

Je kunt de beveiliging en mogelijkheden op het web zien als een spectrum.

De drive-by webversie (links) heeft het laagste vertrouwensmodel, omdat deze het meest toegankelijk moet zijn en daardoor de minste toegang heeft tot het systeem van een gebruiker. Webapps die via de browser zijn geïnstalleerd (midden) krijgen iets meer vertrouwen en kunnen iets dieper in het systeem van een gebruiker integreren. Gebruikers kunnen over het algemeen probleemloos schakelen tussen drive-by webversies en via de browser geïnstalleerde versies van apps.

Daarnaast zijn er nog de zeer betrouwbare, geïsoleerde webapplicaties.

Ze gedragen zich en voelen aan als native apps en bieden toegang tot diepgaande systeemintegraties en krachtige mogelijkheden. Gebruikers kunnen niet zomaar overstappen van native apps naar webapplicaties. Als je dit beveiligingsniveau of deze mogelijkheden nodig hebt, is er geen weg terug.

Wanneer je probeert te bepalen waar je op dit spectrum moet mikken, kies dan standaard voor het beveiligingsmodel met het laagste vertrouwensniveau, zoals een Progressive Web App (PWA) . Dit biedt je het grootste bereik, vereist dat je zelf de minste beveiligingsrisico's beheert en is het meest flexibel voor je ontwikkelaars en gebruikers.

Veilig door ontwerp

Geïsoleerde webapplicaties bieden een zeer betrouwbaar beveiligingsmodel voor webapplicaties. Om dit mogelijk te maken, moeten echter enkele aannames over vertrouwen die de drive-by-web-aanpak hanteert, worden herzien. Kernbouwstenen van het web, zoals servers en DNS, kunnen niet langer expliciet worden vertrouwd. Aanvalsvectoren die relevanter lijken voor native apps, worden plotseling belangrijk. Om toegang te krijgen tot het nieuwe, zeer betrouwbare beveiligingsmodel dat geïsoleerde webapplicaties bieden, moeten webapplicaties daarom worden verpakt, geïsoleerd en beveiligd.

Verpakt

Pagina's en bestanden voor geïsoleerde webapplicaties kunnen niet rechtstreeks vanaf live servers worden aangeboden of via het netwerk worden opgehaald zoals normale webapplicaties. Om toegang te krijgen tot het nieuwe, op vertrouwen gebaseerde beveiligingsmodel, moeten webapplicaties alle benodigde resources bundelen in een ondertekende webbundel . Ondertekende webbundels bundelen alle resources die nodig zijn om een ​​site uit te voeren in een .swbn bestand, aangevuld met een integriteitsblok . Hierdoor kan de webapplicatie veilig in zijn geheel worden gedownload en zelfs offline worden gedeeld of geïnstalleerd.

Dit levert echter een probleem op bij het verifiëren van de authenticiteit van de code van een website: TLS-sleutels vereisen een internetverbinding om te werken. In plaats van TLS-sleutels worden IWA's ondertekend met een sleutel die veilig offline kan worden bewaard. Het goede nieuws is dat als u al uw productiebestanden in een map kunt verzamelen, u deze zonder al te veel aanpassingen kunt omzetten naar een IWA.

Waarschuwing: IWA's sluiten per definitie bepaalde site-architecturen uit. Een site moet al zijn pagina's offline kunnen weergeven. Dat betekent dat server-rendered pagina's niet zijn toegestaan. U dient statisch gegenereerde sites of client-rendered sites als uw primaire architecturen te beschouwen.

Ondertekeningssleutels genereren

Ondertekeningssleutels zijn Ed25519- of ECDSA P-256-sleutelparen, waarbij de privésleutel wordt gebruikt om het pakket te ondertekenen en de publieke sleutel om het pakket te verifiëren. U kunt OpenSSL gebruiken om een ​​Ed25519- of ECDSA P-256-sleutel te genereren en te versleutelen:

# Generate an unencrypted Ed25519 key
openssl genpkey -algorithm Ed25519 -out private_key.pem

# or generate an unencrypted ECDSA P-256 key
openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem

# Encrypt the generated key. This will ask for a passphrase, make sure to use a strong one
openssl pkcs8 -in private_key.pem -topk8 -out encrypted_key.pem

# Delete the unencrypted key
rm private_key.pem

Tip: Als je een Mac gebruikt, voer dan openssl version uit. Als er LibreSSL staat, moet je overschakelen naar OpenSSL. Installeer het met Homebrew door brew install openssl uit te voeren en koppel het om de standaardinstelling te overschrijven met behulp van deze instructies.

Ondertekeningssleutels hebben ook een secundair doel. Omdat een domein, net als een server, kwetsbaar kan zijn voor verlies van controle, kan het niet worden gebruikt om de geïnstalleerde IWA te identificeren. In plaats daarvan wordt een IWA geïdentificeerd door de publieke sleutel van de bundel, die deel uitmaakt van de handtekening en is gekoppeld aan de privésleutel. Dit is een aanzienlijke verandering in de werking van het drive-by web, dus in plaats van HTTPS gebruiken IWA's ook een nieuw schema : isolated-app:// .

Waarschuwing: Omdat de identiteit van uw IWA is gekoppeld aan de privésleutel waarmee deze is ondertekend, hebt u voor elke IWA die u maakt een andere ondertekeningssleutel nodig. Dit betekent ook dat als u dezelfde app met verschillende ondertekeningssleutels ondertekent, deze als verschillende apps worden beschouwd, wat van invloed kan zijn op uw mogelijkheid om een ​​naadloze update-ervaring te bieden.

Bundel je app

Nu je je ondertekeningssleutel hebt, is het tijd om je webapplicatie te bundelen. Je kunt hiervoor de officiële NodeJS- pakketten gebruiken om je IWA's te bundelen en te ondertekenen (er zijn ook Go -commandoregeltools beschikbaar). Gebruik eerst het ` wbn` -pakket en verwijs naar de map met alle productiebestanden van je IWA (hier `dist`) om ze in een niet-ondertekende bundel te verpakken:

npx wbn --dir dist

Opmerking: npx is een NPM- commando (vanaf NPM 7) en wordt hier gebruikt als een handige manier om een ​​pakket uit te voeren zonder het globaal te installeren of als afhankelijkheid aan je project toe te voegen. Het zal altijd proberen de nieuwste versie van het pakket te gebruiken. Als je consistentie in je builds nodig hebt, kun je deze pakketten beter als ontwikkelafhankelijkheden in je project installeren en ze uitvoeren vanuit npm-scripts .

Hiermee wordt een niet-ondertekende webbundel van die map naar out.wbn. Zodra deze is gegenereerd, gebruikt u de versleutelde Ed25519- of ECDSA P-256-sleutel die u eerder hebt aangemaakt om deze te ondertekenen met wbn-sign .

npx wbn-sign -i out.wbn -k encrypted_key.pem -o signed.swbn

Tip: U wordt gevraagd om het wachtwoord dat is gebruikt om uw sleutel te versleutelen. U kunt de omgevingsvariabele WEB_BUNDLE_SIGNING_PASSPHRASE instellen om het wachtwoord automatisch door te geven.

Hiermee wordt een ondertekende webbundel gegenereerd vanuit de niet-ondertekende webbundel met de naam signed.swbn . Na ondertekening geeft de tool ook de Web Bundle ID en de Isolated Web App Origin weer. De Isolated Web App Origin is hoe uw IWA in de browser wordt geïdentificeerd.

Web Bundle ID: ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic
Isolated Web App Origin: isolated-app://ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic/

Let op: hoewel uw IWA door deze oorsprong wordt geïdentificeerd, openen IWA's in een eigen venster zonder adresbalk, net als een PWA, en is het onwaarschijnlijk dat gebruikers dit ooit zullen zien.

Als je Webpack , Rollup of een tool gebruikt die hun plugins ondersteunt (zoals Vite ), kun je een van de bundler-plugins ( Webpack , Rollup ) gebruiken die deze pakketten omwikkelt in plaats van ze rechtstreeks aan te roepen. Hierdoor wordt een ondertekende bundel als output van je build gegenereerd.

Tip: Je hoeft deze plugins alleen op te nemen in je productiebuildpipeline, niet in je ontwikkelpipeline.

Test je app

Je kunt je IWA op twee manieren testen: door je ontwikkelserver via de ingebouwde IWA-ontwikkelaarsproxy van Chrome te laten draaien, of door je gebundelde IWA te installeren. Hiervoor heb je Chrome of ChromeOS 120 of hoger nodig, moet je de IWA-vlaggen inschakelen en je app installeren via Chrome's Web App Internals.

1. Schakel de chrome://flags/#enable-isolated-web-app-dev-mode -vlag in.
2. Test je IWA door naar de pagina Web App Internals van Chrome te gaan op chrome://web-app-internals

Op de pagina Web App Internals heb je twee opties: Install IWA with Dev Mode Proxy of Install IWA from Signed Web Bundle .

Als u installeert via een Dev Mode Proxy, kunt u elke URL, inclusief sites die vanaf een lokale ontwikkelserver draaien, als een IWA installeren zonder deze te bundelen, mits ze voldoen aan de overige IWA-installatievereisten. Na installatie wordt een IWA voor die URL aan uw systeem toegevoegd met de juiste beveiligingsbeleidsregels en -beperkingen en toegang tot IWA-specifieke API's. Er wordt een willekeurige identificatiecode aan toegewezen. Chrome Dev Tools is in deze modus ook beschikbaar om u te helpen bij het debuggen van uw applicatie. Als u installeert vanuit een Signed Web Bundle, uploadt u uw ondertekende, gebundelde IWA en wordt deze geïnstalleerd alsof deze door een eindgebruiker is gedownload.

Op de pagina Web App Internals kunt u ook geforceerde updatecontroles uitvoeren voor alle applicaties die zijn geïnstalleerd via Dev Mode Proxy of vanuit een Signed Web Bundle, om zo het updateproces te testen.

Geïsoleerd

Vertrouwen is cruciaal voor geïsoleerde webapplicaties. Dit begint met de manier waarop ze draaien. Gebruikers hebben verschillende mentale modellen van wat een app kan en zou moeten kunnen doen, afhankelijk van of deze in een browser of in een apart venster draait. Over het algemeen gaan ze ervan uit dat apps in een apart venster meer toegang hebben en krachtiger zijn. Omdat geïsoleerde webapplicaties toegang kunnen krijgen tot API's met een hoge mate van vertrouwen, moeten ze in een apart venster draaien om aan dit mentale model te voldoen. Dit scheidt ze visueel van de browser. Maar het gaat verder dan alleen visuele scheiding.

Geïsoleerde webapps (IWA's) werken via een ander protocol dan websites die in de browser worden weergegeven ( isolated-app versus http of https ). Dit betekent dat elke IWA volledig gescheiden is van websites die in de browser draaien, zelfs als ze door hetzelfde bedrijf zijn ontwikkeld, dankzij het same-origin-beleid . Ook de opslag van IWA's is van elkaar gescheiden. Dit zorgt er samen voor dat content van verschillende oorsprong niet kan lekken tussen verschillende IWA's of tussen IWA's en de normale browseomgeving van een gebruiker.

Maar noch isolatie, noch het bundelen en ondertekenen van de code van een site zijn nuttig om vertrouwen te wekken als een IWA na installatie willekeurige code kan downloaden en uitvoeren. Om dit te garanderen en tegelijkertijd IWA's in staat te stellen verbinding te maken met andere sites voor content, hanteren IWA's een strenge set contentbeveiligingsbeleidsregels :

• Staat alleen JavaScript uit de bundel toe; Wasm kan echter wel worden uitgevoerd, ongeacht de bron. ( script-src )
• Hiermee kan JavaScript gegevens ophalen van beveiligde, niet-localhost cross-origin domeinen, verbinding maken met WebSocket- en WebTransport- eindpunten, en blob- en data- URL's ( connect-src ).
• Beschermt tegen cross-site script injection (XSS)-aanvallen op het DOM door te reguleren hoe DOM-manipulatiefuncties kunnen worden gebruikt ( require-trusted-types-for ).
• Hiermee kunnen frames, afbeeldingen, audio en video van elk HTTPS-domein worden geladen ( frame-src , img-src , media-src ).
• Hiermee kunnen lettertypen uit de bundel en blobs ( font-src ) worden gebruikt.
• Sta inline CSS of CSS uit de bundel toe ( style-src ).
• De elementen <object> , <embed> en <base> kunnen niet worden gebruikt ( object-src en base-uri ).
• Staat alleen resources uit de bundel toe voor alle andere CSP-gedekte verzoeken ( default-src ).

Opmerking: Voor IWA's verwijst self naar resources die vanuit de bundel worden geladen. Dit sluit blob: filesystem: en andere lokale schema's uit, evenals inline scripts.

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval';
  connect-src 'self' https: wss: blob: data:;
  require-trusted-types-for 'script';
  frame-src 'self' https: blob: data:;
  img-src 'self' https: blob: data:;
  media-src 'self' https: blob: data:;
  font-src 'self' blob: data:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  default-src 'self';

Deze CSP's zijn niet voldoende om volledig te beschermen tegen potentieel kwaadaardige code van derden. IWA's zijn ook cross-origin geïsoleerd en stellen headers in om de mogelijkheden van externe bronnen om ze te beïnvloeden te beperken:

• Sta alleen resources uit de bundel of cross-origin resources toe die expliciet zijn gemarkeerd als CORS- ondersteunend, hetzij met een cross-origin resource policy (CORP) header ingesteld, hetzij met het crossorigin attribuut ( Cross-Origin-Embedder-Policy ).
• Cross-origin-verzoeken zonder CORS-status verbieden ( Cross-Origin-Resource-Policy )
• Het proces isoleert de browsecontext van documenten van een andere oorsprong, waardoor verwijzingen naar window.opener en toegang tot globale objecten worden voorkomen ( Cross-Origin-Opener-Policy ).
• Voorkom dat de site wordt ingesloten in een frame of iframe (CSP, frame-ancestors )

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: frame-ancestors 'self'

Zelfs met deze beperkingen is er nog één potentiële aanval waar IWA's tegen beschermen: sequence breaking attacks. Een sequence breaking attack vindt plaats wanneer kwaadwillende content van derden probeert een verwarrende en mogelijk misbruikbare gebruikerservaring te creëren door op een onverwachte manier naar een pagina te navigeren, bijvoorbeeld door direct naar een interne instellingenpagina te gaan. IWA's voorkomen dit door willekeurige deep linking vanaf externe sites te blokkeren en alleen toe te staan ​​dat applicaties worden geopend via goed gedefinieerde toegangspunten, zoals een start_url , een protocol handler , een share target of via een launch handler .

In lockdown

Verpakking en isolatie bieden een aantal garanties met betrekking tot wat er mag worden uitgevoerd en waar het vandaan komt, maar de dynamische aard van machtigingen op het web betekent dat ze op zichzelf niet kunnen garanderen dat een webapplicatie alleen de benodigde mogelijkheden gebruikt. Omdat verschillende mogelijkheden verschillende beveiligingsaspecten met zich meebrengen, zal een gebruiker of beheerder willen controleren welke machtigingen een IWA mag gebruiken, net zoals ze dat kunnen doen met andere native apps zoals Android en iOS voordat ze een app installeren of bijwerken.

Om dit mogelijk te maken, blokkeren geïsoleerde webapps standaard alle toestemmingsverzoeken. Ontwikkelaars kunnen vervolgens de gewenste toestemming inschakelen door een veld permissions_policy toe te voegen aan het manifest van hun webapp. Dit veld bevat sleutel/waarde-paren van toestemmingsbeleidsrichtlijnen en toestemmingslijsten voor elke toestemming die de IWA, of een onderliggend frame zoals een Controlled Frame of een iframe, kan aanvragen. Het toevoegen van een toestemming hier verleent deze niet automatisch; in plaats daarvan maakt het de toestemming beschikbaar om te worden aangevraagd wanneer een verzoek voor die functionaliteit wordt gedaan.

Stel dat u een IWA (Intelligent Web Application) bouwt voor het volgen van een wagenpark. Mogelijk wilt u dat uw IWA de locatie van de gebruiker kan opvragen, en dat een ingebedde kaart ook de locatie kan opvragen. U wilt wellicht ook dat elke ingebedde website in volledig scherm kan worden weergegeven voor een meeslepende ervaring voor de gebruiker. Om dit te realiseren, stelt u het volgende machtigingsbeleid in uw Web App Manifest in:

"permissions_policy": {
   "geolocation": [ "self", "https://map.example.com" ],
   "fullscreen": [ "*" ]
}

Omdat WebBundles ook headers voor het Permissions Policy kunnen specificeren, zijn alleen de machtigingen toegestaan ​​die in beide zijn gedeclareerd, en dan zijn alleen origins toegestaan ​​die voorkomen in de whitelists die in beide zijn opgenomen.

Benoemd en van een versie voorzien

Normale webapps gebruiken hun domeinnaam om zich aan gebruikers te identificeren en kunnen worden bijgewerkt door de code op dat domein aan te passen. Vanwege de beveiligingsbeperkingen van geïsoleerde webapps moeten identiteit en updates echter anders worden afgehandeld. Net als progressieve webapps hebben geïsoleerde webapps een webapp-manifestbestand nodig om zich aan gebruikers te identificeren.

Tip: Het web-app-manifest van een geïsoleerde web-app wordt niet in de HTML opgenomen, omdat het tijdens de installatie vindbaar moet zijn. Het moet zich bevinden op /.well-known/manifest.webmanifest en in uw IWA-pakket worden opgenomen.

Webapp-manifest

Geïsoleerde webapps delen dezelfde belangrijke manifesteigenschappen voor hun webappmanifest als PWA's, met enkele kleine verschillen. Zo werkt display iets anders; zowel browser als minimal-ui worden gedwongen tot een minimal-ui -weergave, en fullscreen en standalone worden beide gedwongen tot een standalone -weergave (aanvullende display_override opties werken zoals verwacht). Daarnaast zijn er nog twee velden die moeten worden opgenomen: version en update_manifest_url .

• version : Vereist voor geïsoleerde webapplicaties. Een tekenreeks bestaande uit een of meer gehele getallen gescheiden door een punt ( . ). Uw versie kan iets eenvoudigs zijn zoals 1 , 2 , 3 , enz., of iets complexer zoals SemVer ( 1.2.3 ). Het versienummer moet overeenkomen met de reguliere expressie ^(\d+.?)*\d$ .
• update_manifest_url : Optioneel , maar aanbevolen veld dat verwijst naar een HTTPS-URL (of localhost voor testdoeleinden) waar een updatemanifest van de webapplicatie kan worden opgehaald.

Een minimaal manifest voor een geïsoleerde webapplicatie kan er bijvoorbeeld zo uitzien:

{
  "name": "IWA Kitchen Sink",
  "version": "0.1.0",
  "update_manifest_url": "https://example.com/updates.json",
  "start_url": "/",
  "icons": [
    {
      "src": "/images/icon.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "any"
    },
    {
      "src": "/images/icon-mask.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "maskable"
    }
  ]
}

Manifest voor het bijwerken van de webapplicatie

Een Web Application Update Manifest is een JSON-bestand dat elke versie van een bepaalde webapplicatie beschrijft. Het JSON-object bevat één verplicht veld, version , dat een lijst is van objecten met daarin version , src en channels .

• version - Het versienummer van de applicatie, hetzelfde als het version in het Web App Manifest.
• src - De HTTPS-URL (of localhost voor testdoeleinden) die verwijst naar de gehoste bundel voor die versie (het .swbn bestand). Relatieve URL's zijn relatief ten opzichte van het Web Application Update Manifest-bestand.
• channels - Een lijst met tekenreeksen om het updatekanaal te identificeren waartoe deze versie behoort. Een speciaal default wordt gebruikt om het primaire kanaal te beschrijven dat wordt gebruikt als er geen ander kanaal is geselecteerd.

Je kunt ook een veld channels toevoegen, een object met je kanaal-ID's en een optionele name eigenschap voor elke ID om een ​​leesbare naam te geven (ook voor het default ). Een kanaal dat geen name eigenschap heeft of niet in het channels object is opgenomen, gebruikt zijn ID als naam.

Een minimaal updatemanifest kan er bijvoorbeeld zo uitzien:

{
  "versions": [
    {
      "version": "5.2.17",
      "src": "https://cdn.example.com/app-package-5.2.17.swbn",
      "channels": ["next", "5-lts", "default"]
    },
    {
      "version": "5.3.0",
      "src": "v5.3.0/package.swbn",
      "channels": ["next", "default"]
    },
    {
      "version": "5.3.1",
      "src": "v5.3.1/package.swbn",
      "channels": ["next"]
    },
  ],
  "channels": {
    "default": {
      "name": "Stable"
    },
    "5-lts": {
      "name": "5.x Long-term Stable"
    }
  }
}

In dit voorbeeld zijn er drie kanalen: default , dat de naam Stable krijgt, 5-lts dat de naam 5.x Long-term Stable krijgt, en next , dat de naam next krijgt. Als een gebruiker zich op kanaal 5-lts bevindt, krijgt hij versie 5.2.17 ; als hij zich op kanaal default bevindt, krijgt hij versie 5.3.0 ; en als hij zich op kanaal next bevindt, krijgt hij versie 5.3.1 .

Updatemanifesten voor webapplicaties kunnen op elke server worden gehost. Er wordt elke 4-6 uur gecontroleerd op updates.

Beheerd door de beheerder

Bij de eerste lancering kunnen Isolated Web Apps alleen worden geïnstalleerd op Chromebooks die worden beheerd door Chrome Enterprise door een beheerder via het beheerderspaneel .

Om te beginnen ga je vanuit je beheerderspaneel naar Apparaten > Chrome > Apps en extensies > Gebruikers en browsers . Op dit tabblad kun je apps en extensies toevoegen vanuit de Chrome Web Store, Google Play en het web voor gebruikers binnen je organisatie. Je voegt items toe door op de gele zwevende knop 'Toevoegen' ( + ) rechtsonder in het scherm te klikken en het type item te selecteren dat je wilt toevoegen.

Tip: U kunt alleen items toevoegen op het niveau van de organisatie-eenheid (OU); als u geen OU hebt geselecteerd in het zijpaneel op de pagina Apps en extensies , of als u zich niet in het tabblad Gebruikers en browsers bevindt, wordt de knop Toevoegen niet weergegeven.

Wanneer u het venster opent, ziet u een pictogram van een vierkant in een vierkant, met het label ' Een geïsoleerde web-app toevoegen' . Als u erop klikt, wordt een pop-upvenster geopend waarmee u een IWA aan uw organisatie-eenheid (OU) kunt toevoegen. Hiervoor hebt u twee gegevens nodig: de Web Bundle ID van de IWA (gegenereerd op basis van de openbare sleutel van uw app en weergegeven nadat de app is gebundeld en ondertekend) en de URL naar het Web App Update Manifest voor de IWA. Na de installatie beschikt u over de standaardopties van het beheerderspaneel om de IWA te beheren.

• Installatiebeleid : Hoe u IWA wilt installeren: geforceerde installatie, geforceerde installatie en vastzetten in het ChromeOS-systeem, of installatie voorkomen.
• Starten bij inloggen : Hoe u wilt dat de IWA wordt gestart, kunt u de gebruiker toestaan ​​deze handmatig te starten, de IWA te forceren bij het inloggen maar de gebruiker de mogelijkheid geven deze te sluiten, of de IWA te forceren bij het inloggen en te voorkomen dat deze wordt gesloten.

Zodra de app is opgeslagen, wordt deze geïnstalleerd de volgende keer dat er een beleidsupdate wordt toegepast op Chromebooks in die OU. Na installatie controleert het apparaat van de gebruiker elke 4-6 uur op updates via het Web App Update Manifest.

Naast het geforceerd installeren van IWA's kunt u ook automatisch bepaalde machtigingen toekennen, net zoals bij andere webapplicaties. Ga hiervoor naar Apparaten > Chrome > Webmogelijkheden en klik op de knop ' Oorsprong toevoegen' . Plak in het Origin / site pattern field de Web Bundle ID van de IWA ( isolated-app:// automatisch als protocol wordt toegevoegd). Vervolgens kunt u de toegangsniveaus voor verschillende API's instellen (toegestaan/geblokkeerd/uitgeschakeld), waaronder vensterbeheer, lokaal lettertypebeheer en de schermbewakings- API. Voor API's waarvoor mogelijk extra toestemming van een beheerder nodig is, zoals de verplichte schermbewakings-API, verschijnt een extra dialoogvenster om uw selectie te bevestigen. Sla uw wijzigingen op zodra u klaar bent en uw gebruikers kunnen uw IWA direct gebruiken!

Werken met extensies

Hoewel Isolated Web Apps (IWA's) standaard niet met extensies werken, kunt u uw eigen extensies eraan koppelen. Hiervoor moet u het manifestbestand van de extensie bewerken. Het gedeelte externally_connectable in het manifest definieert met welke externe webpagina's of andere Chrome-extensies uw extensie kan communiceren. Voeg de oorsprong van uw IWA toe onder het veld matches in externally_connectable (zorg ervoor dat u het ` isolated-app:// schema opneemt):

{
  "externally_connectable": {
    "matches": ["isolated-app://79990854-bc9f-4319-a6f3-47686e54ed29/*"]
  }
}

Hoewel dit ervoor zorgt dat uw extensie in de Isolated Web App kan draaien, kan deze er geen inhoud in injecteren; u bent beperkt tot het uitwisselen van berichten tussen de extensie en uw IWA.