WS-Architecture, forretningsprocesser og sikkerhed

Transkript

1 Husk at bestille Arkitektur for digital forvaltning på danmark.dk 4,733336&_dad=portal&_schema=PORTAL (c) SOA Network, WS-Architecture, forretningsprocesser og sikkerhed Datalogisk Institut 5. januar 2005 v/ Vidensleverandør Henrik Hvid Jensen, SOA Network henrikhvid@soanetwork.dk (c) SOA Network,

2 Forretningsprocesser Orkestrering og koreografi (c) SOA Network, Kernen i en serviceorienteret arkitektur (c) SOA Network,

3 Netværkscentreret Intelligensen ligger i netværket Fælles forståelse af metoder til at interface til netværket Uafhængighed af den underliggende teknologi Strategi bør være deltagelse i procesnetværk At være en fleksibel komponent af et større netværk KMS store ekspertise om kort og geodata skal være til rådighed for hele samfundet Kilde: Kort og Matrikelstyrelsens indsatsområder Væsentligt skifte i hvordan man designer forretningsprocesser Globale tekniske og forretningsmæssige standarder er nøgleordet Nedbrydelse af virksomhedssiloer Det forudsætter, at den enkelte institution opbygger egne itsystemer med forståelse for netop sammenhængen til det offentliges it-anvendelse i sin helhed, og at den enkelte institution er med til at tage ansvar for principperne for opbygning af itsystemerne Kilde: Arkitektur for digital forvaltning (c) SOA Network, Behov for standardiseret forretningsprocesbeskrivelse Forretningsproces tages ud af it-applikationerne Lægges i et lag på toppen Udveksle information baseret på regler, politikker og aktiviteter Bygge forretningsprocesser på toppen af Web Service stakken Uafhængighed af leverandør Samme procesbeskrivelse kan genbruges uafhængigt at softwareløsning (c) SOA Network,

4 Alternativet Proprietærer løsninger til Web Service standarden (Låst til en leverandør) Inkompatibilitet Genbrug af processer på tværs vanskeliggøres Ringere værktøjer Højere priser på produkter og tjenester Intern/ekstern procesintegration vil forblive omkostningsfuldt Web Services vil bare være en lettere måde at lave en til en-integration på. (c) SOA Network, Servicekomposition Venter på at en begivenhed indtræffer Fortolker en besked Beslutningspunkt, hvor processen, afhængig af data i beskeden, vil vælge en retning frem for en anden Parallel udførsel Kalder en ekstern service og venter på svar Længerevarende processer Signalerer en fejlagtig situation og definerer kompenserende aktiviteter Understøtter både B2B og EAI (c) SOA Network,

5 Orkestrering Overordnet dirigent som opbygger forretningsprocesser Definerer krav for deltagelse Rekrutterer virksomheder Definerer standarder for kommunikation og koordinering Strukturerer en passende informationsarkitektur Sammensætter multiple deltager for at skræddersy det til kunder eller produkter Har det ultimative ansvar for resultatet (c) SOA Network, Centralt dokument (c) SOA Network,

6 Ejendomssammenlægning som en orkestreret forretningsproces Et program hos en landinspektør kalder Web Servicen Sammenlægning Et program hos KMD kalder Web Servicen Sammenlægning Et program hos KMS kalder Web Servicen Sammenlægning Sammenlægning Hele processen orkestreres via portalen og tilbydes som Web Servicen sammenlægning Indhent tinglysnin gsattest Samme ejer? Nej Afvis sammenlægning Tinglysningsdommerens proces til indhentning af tinglysningsattest tilbydes som Web Service Ja Processer til understøttelse af panthaveropgør tilbydes som Web Services Panthaver -opgør Nej Ensartet behæftet? Foretag sammenlægning (c) SOA Network, Ja Kort og Matrikelstyrelsens proces til sammenlægning tilbydes som Web Service Koreografi Beskriver kun den synlige opførsel mellem Web Services Definerer ikke de eksekverbare forretningsprocesser Et enkelt dokument beskriver kun en partners deltagelse i beskedudvekslingen Ingen enkelt kontrollerende proces der håndterer interaktionen (c) SOA Network,

7 Overblik over BPEL (c) SOA Network, Strukturen af en BPELProces <process...> <partners>... </partners> <!-- Web services som processen interagere med --> <containers>... </containers> <! Data brugt af processen --> <correlationsets>... </correlationsets> <! Brugt til at understøtte asynkrone interaktioner --> <faulthandlers>... </faulthandlers> <! Alternativ eksekveringssti for at håndtere fjelbetingelser --> <compensationhandlers>... </compensationhandlers> <! Kode der skal eksekverers når en aktivitet skal omgøres --> (activities)* <! Hvad processen faktisk gør --> </process> (c) SOA Network,

8 Salg af toaster online (B2B) (c) SOA Network, Salg af online toaster (EAI) (c) SOA Network,

9 Autoriser betaling (c) SOA Network, Alloker varer på lageret (c) SOA Network,

10 Første skridt Delt vokabular beskrevet i et WSDL dokument Online toaster store schema.xml Næste skridt er at konstruere WSDL interface til Web Servicen (c) SOA Network, Køber / sælger beskedudveksling Ingen requestresponse interaktion Kunden har et WSDL interface designet til at shoppen holder den opdateret om workflow Customer service's WSDL interface.xml (c) SOA Network,

11 Butik / bank beskedudveksling Synkron requestresponse kommunikation Kortlivet Stoler på banks performance Ændres sjældent Bank service WSDL.xml (c) SOA Network, Shoppens WSDL OnlineToasters.com WSDL interface.xml En porttype deklaration for at bestille toasters Property deklarationer bruges til at identificere og samle beskeder og workflow instanser, der logisk tilhører samme kundeordre Er også startpunktet for interfacet til shoppen Næste trin er at integrere bank og kunde i workflow (c) SOA Network,

12 BPEL og WSDL. Partnere Køber Bank WSDL Bank Service Link Type (c) SOA Network, ServiceLinkType Hver rolle i et BPEL service link er defineret ved Et navn for den rolle Et antal porttype deklarationer som en enhed der spiller den rolle skal understøtte Service link declarations.xml Enhver Web Service der vil spille customer-rolen skal understøtte CustomerPortType porttype Og en vendor skal understøtte ToastVendorPortType Banken er ligeglad med den anden part rolle, da dens Web Service er en synkron request/response porttype er typisk fra forskellige namespace En del af WSDL-definitionen (c) SOA Network,

13 Hvordan ved man hvor den modtagne besked hører til? Correlation sæt definerer en unik nøgle Bruges til at henføre beskeder til en specifik procesinstans Correlation set declaration.xml Unik nøgle består af CustomerOrderPropert og OrderTimestampProperty fra OnlineToasters.com WSDL interface.xml Er ikke mere i WSDL dokumentet (c) SOA Network, BPEL Data Model Globale datavariable som WSDL message typer Aktiviteternes input/output er gemt I globale variable Tildelingsaktiviteter flytter data rundt Container declarations.xml (c) SOA Network,

14 Partnerbeskrivelser Partner declarations.xml Brugervenligt navngivning af enheder som workflow algoritmen kommunikere med Specificerer hvilken rolle af den tilhørende servicelinktype som spilles af virksomheden og hvilken af dne pågældende partner (c) SOA Network, BPEL Basale aktiviteter <invoke partner=... porttype=... operation=... inputcontainer=... outputcontainer=... /> <! Proces kalder en operation hos en partner: --> <receive partner=... porttype=... operation=... container=... [createinstance=... ]/> <! Proces modtager et opkald fra en partner: --> <reply partner=... porttype=... operation=... container=... /> <! Proces sender svarbesked til i partnerkald: --> <assign> <copy> <from container=... /> <to container=... /> </copy>+ </assign> <! Data tildeling mellem container: --> (c) SOA Network,

15 BPEL strukturerde aktiviteter <sequence> <! eksekverer aktiviteter sekventielt--> <flow> <! eksekverer aktiviteter parallelt--> <while> <! Gentager eksekvering af aktiviteter så længe betingelsen er opfyldt--> <pick> <! Flere hændelseaktiviteter (modtag besked, timerhændelse) scheduleret til at eksekvere parallelt; den første vælges og korresponderende kode er eksekveret. --> <link...> <! definerer en kontrolafhængighed mellem en kildeaktivitet og et target --> (c) SOA Network, Eksempel <sequence> <receive.../> <flow> <sequence> <invoke.../> <while... > <assign>... </assign> </while> </sequence> <sequence> <receive.../> <invoke... > </sequence> </flow> <reply> </sequence> Seq Flow Seq While Seq (c) SOA Network,

16 Modtag en kundeorder Receiving a customer order.xml Receive aktiviteten er indgangspunkt til workflowen Det acceptere et kald fra en kunde til purchasetoaster operation gemmer indholdet af beskeden i PurchaseOrders containerne Første opgave er at validerer kreditkortet Authorizing a credit card payment.xml Overføre til rette container Kalder bankens BankPortType (c) SOA Network, BPEL Handler og Scope En scope er et antal aktiviteter. Hvert scope kan have to typer af handlers tilknyttet: Scope Fault Handler Fault handlers. Mange kan tilknyttes for hver forskellig fejltype. En fault handler definerer alternative eksekveringsstier når en fejl sker inden i et scope Compensation handlers. En enkelt compensation handler Compensation per scope. Handler En compensation handler bruges til at omgøre arbejde udført af et allerede afsluttet scope Omgøre forretningseffekten En compensation handler kan kaldes af en fault handler eller compensation handler af dets indkapslede scope (c) SOA Network,

17 Opsummering BPEL udvider interoperabiliteten til også at inkludere forretningsprocesser Kræver fælles definition af forretningsprocesser WS-I arbejder også på dette Standarderne vil reducere omkostninger Derved vil forretningsprocesintegrationen have forøget attraktivitet Hav altid orkestreringskonceptet i baghovedet når man udvikler sin serviceorienterede løsninger og arkitektur (c) SOA Network, Tak for i dag (c) SOA Network,

18 En behændig sikkerhedsinfrastruktur (c) SOA Network, Web Services tilføjer nye risici It-funktionalitet gøres tilgængelig udover virksomhedens mure Sikkerhedsløsningen må ikke sætte unødige grænser for fleksibiliteten eller samarbejdspartnere Omkostningseffektivt for både virksomheden såvel som dets partnere Alle skal kunne bruge deres eksisterende sikkerhedsløsning Vil kræve Web Service-orienterede udvidelser Web Service vil tilføje hundredvis af enkelte services til virksomhedens it-miljø Distribuerede natur gør det vanskeligt at håndhæve sikkerhedspolitikker Fundamental sikkerhedsprincipper Autentifikation af bruger (uden tæt kobling) Sikkerhed på tværs af mange led Selektiv funktionsadgang afhængig af brugeren (c) SOA Network,

19 WS-Security Abstrakt model for Web Service-sikkerhed Målet er sikre og interoperable løsninger ved brug af heterogene systemer Krav til applikationssikkerhed skal beskrives abstrakt Uafhængigt af de enkelte specifikke mekanismer der bruges Ingen krav om specielle sikkerhedsløsninger Udover at kunne deltage i WS-Security-modellen Integration gennem abstraktionen af enkelt sikkerhedsmodel sikrer interoperabilitet Sprog- og platformuafhængighed (c) SOA Network, Indhold i WS-Security Udvider SOAP-<header> elementet Beskriver hvordan man på en transportneutral måde inkluderer sikkerhedsmekanismer i en SOAP-besked Der introduceres ikke nye mekanismer eller algoritmer (c) SOA Network,

20 WS-Security modellen En Web Service kan kræve at en besked fremviser påstand (Claims) (navn, nøgle, tilladelser, evne osv.) De krævede påstande og relateret information betegnes som en policy En anmoder kan sende beskeder med bevis for de krævede påstande ved at associere secuity tokens med beskeden Kan også indhentes på vegne af anmoderen ved at bruge andre Web Services (security token services) Security token services Kan kræve deres egne påstande Mægler tillid mellem forskellige troværdighedsdomæner ved at udstede security tokens. (c) SOA Network, WS-Security specifikationer (c) SOA Network,

21 WS-Policy Udtrykke muligheder, krav og generelle karakteristika Eksemplet Bruger WS-SecurityPolicy assertions (påstand) WS-PolicyAttachment beskriver mekanismer for hvordan WS-Policy associeres med XMLelementer, WSDL dokumenter og UDDIelementer WS-PolicyReference tillader reference via en URI til en generel politik <wsp:policy> <wsp:exactlyone> <wsse:securitytoken> <wsse:tokentype>wsse:kerberosv 5TGT</wsse:TokenType> </wsse:securitytoken> <wsse:securitytoken> <wsse:tokentype>wsse:x509v3</ wsse:tokentype> </wsse:securitytoken> </wsp:exactlyone> </wsp:policy> (c) SOA Network, WS-Trust Specifikation for opbyggelse af troværdigheds-relationer F.eks. med Security Token Service Mellem individuelle Web Services Hvordan anmodes og afleveres forskellige sikkerheds-token Inkluderes i en SOAP-besked <RequestSecurityToken Context="..."> <TokenType>...</TokenType> <RequestType>...</RequestType> <Base>...</Base> <Supporting>...</Supporting>... </RequestSecurityToken> <RequestSecurityTokenResponse Context="..."> <TokenType>...</TokenType> <RequestedSecurityToken>...</Req uestedsecuritytoken>... </RequestSecurityTokenResponse> (c) SOA Network,

22 WS-Privacy / P3P Organisationer danner, håndterer WS-Privacy-specifikationen beskriver og bruger Web Service en model for hvordan et privacy-sprog kan inkluderes i en WS-Policy Disse organisationer har behov beskrivelse for at informere om deres privacypolitikker privacy-påstande med en besked WS-Security vil associere disse De skal også kræve at indkomne WS-Trust mekanismer kan bruges til anmodninger overholder disse at evaluere disse privacy-påstande for politikker både brugerpreferencer og P3P- Platform for Privacy organisationers påstande Preferences P3P-forberdte hjemmesider Er et system til at gøre beskriver deres privacy-politikker i hjemmesiders privacy-politkker et standard maskinlæsbart format maskinlæsbare (XML) Forbedrer brugerkontrol ved at P3P-forberedte browser kan placere privacy-politkker hvor automatisk læse denne beskrivesle brugerne kan finde dem, I et format og sammenligne den med som brugeren kan forstå og gør det muligt for brugeren at reagere på forbrugerens egne privacy-krav hvad de ser En model for hvordan privacykrav og organisatioriske privacy-praksis er overført (c) SOA Network, P3P eksempler fra W3C Scenario 2: Web site busy.example.com uses a content distribution network called cdn.example.com to host its images so as to reduce the load on its servers. Thus, all of the images on the site have URIs at cdn.example.com. CDN acts as an agent to Busy in this situation, and collects no data other than log data. This log data is used only for Web site and system administration in support of providing the services that Busy contracted for. Busy's privacy policy applies to the images hosted by CDN, so Busy uses the HINT element in its policy reference file to point to a suitable policy reference file at CDN, indicating that such images are covered by example.com P3P policy. Scenario 3: Web site busy.example.com also has a contract with an advertising company called clickads.example.com to provide banner ads on its site. The contract allows Clickads to set cookies so as to make sure each user does not see a given ad more than three times. Clickads collects statistics on how many users view each ad and reports them to the companies whose products are being advertised. But these reports do not reveal information about any individual users. As was the case in Scenario 2, Busy's privacy policies applies to these ads hosted by Clickads, so Busy uses the HINT element in its policy reference file to point to a suitable policy reference file at Clickads, indicating that Busy P3P policy applies to such embedded content served by clickads.example.com. The companies whose products are being advertised need not be mentioned in the Busy privacy policy because the only data they are receiving is aggregate data. (c) SOA Network,

23 WS-SecureConversation Hvorledes opbygges en sikker konversation mellem to Web Services (c) SOA Network, WS-Federation Muliggør deling af identitet-, autentifikationog autorisations-data ved brug af forskellige eller ensartede mekanismer Mægler troværdighed og sikkerheds-token udveksling Lokale identiteter er ikke krævet ved endelig service Frivillig skjuling af identitet information og andre attributter (c) SOA Network,

24 WS-Authorization Definerer hvordan services skal håndtere autorisationsdata og politikker SAML er ved at blive standarden (c) SOA Network, SSL fungerer til simple Web Services (c) SOA Network,

25 Kryptering på tværs af flere kommunikationsteknologier (c) SOA Network, Hul mellem dekryptering og kryptering (c) SOA Network,

26 Sikkerhed hele vejen (c) SOA Network, Elementvis kryptering og signering (c) SOA Network,

27 Eksempel (c) SOA Network, Nogle af de vigtigste komponenter XML Signatur Man kan signere et komplet XML-dokument Man kan signere et enkelt element i et XML-dokument Man kan signere indholdet i et XML-element Man kan signere ikke-xml-data (f.eks. jpg-billeder) XML Encryption Man kan kryptere et komplet XML-dokument Man kan kryptere et enkelt element i et XML-dokument Man kan kryptere indholdet i et XML-element Man kan kryptere ikke-xml-data (f.eks. jpg-billeder) (c) SOA Network,

28 XML Encryption <EncryptedData xmlns=' Type=' <EncryptionMethod Algorithm=' <ds:keyinfoxmlns:ds=' <ds:keyname>john Smith</ds:KeyName> </ds:keyinfo> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> (c) SOA Network, XML Signatur <SignatureId="MySignature"xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <ReferenceURI=" <Transforms> <Transform Algorithm=" "/> </Transforms> <DigestMethodAlgorithm=" <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> (c) SOA Network, </Signature>

29 Autentifikation og autorisation over flere led Autentifikations- og autorisationsinformation skal følge forespørgelsen på tværs af organisationer, applikationer, netværk Hver med deres egen sikkerhedsmekanisme Samtidig beskytte hver enkelt virksomheds unikke relationer med brugeren Identiteten ikke nødvendig, relevant autorisationsinformation er tilstrækkelig Væk fra menneske til maskin-interaktion til maskin til maskininteraktion Mister den menneskelige intuition Web Service skal have adgang til slutbruger information for at kunne træffe autorisationsbeslutning Kan ikke anmode om indtastning af password Etablere tillid mellem Web Services (c) SOA Network, Forbunden identitet muligheden for sikkert at kunne genkende og forstå en brugers identitet ejet af andre organisationer Standarden SAML bruges til at udtrykke autorisation og autentifikation Attributter om brugeren Universel måde at dele autorisations- og autentifikationsinformation Platformneutral Relevant sikkerhedsinformation tilgængelig efter kommunikationen er ophørt Bruges til engangsautentificering og autorisation Single sign on Tillader organisationer at acceptere autentificerede bruger fra andre organisationer XML baseret beskeder der fortæller (assertions) Om brugeren er autentificeret Hans rettigheder, roller og adgang Godkendelsesgrænse Hvordan han kan bruge data og ressourcer Må han købe ting (c) SOA Network,

30 SAML påstande (c) SOA Network, Beskyttelse mod angreb SOAP muliggør angreb på applikationsniveau Krav om firewalls med viden om indhold i en SOAP besked Konfigurationsdata udstiller Web Servicen XML Schema WSDL Dokumenter WS-Policy Afhængighed af partneres sikkerhedspolitikker Afhængig af fælles protokoller Forøger antallet af potentielle mål med det samme våben Men applikationerne er individuelle Standardværktøjer Genafspilningsangreb <timestamp> i SOAP-headeren (c) SOA Network,

31 Trusler XML/SOAP manipulering Usikker konfigurationsdata (WSDL) Parameter ændring Oversize payloads Schema forgiftning WSDL skanning kan gætte andre metoder SQL injektion Gemmer SQL kommandoer i et inputfelt Network ping of death Gentagne SOAP request (c) SOA Network, Sikkerhed opsummering Sikkerheden skal være i orden Web Service gør det lettere at udstille data og forretningsprocesser Sikkerhedsinformation skal sendes sammen med det dokument den relaterer til Sikkerheden skal også være løst koblet Nye udfordringer for firewallen Benyt WS-Security nu Også til simple en til en-web Service løsninger Forberedt til fremtiden Sikkerhed opnås gennem godt design ikke bare ved brug af standarder (c) SOA Network,

32 Tak for i dag (c) SOA Network, Hvad håndteres af Ws- Security Overordnet er det multi-hop XML messaging. Specielt er det sikkerhed for en SOAP besked En måde at sende autentifikations bevis til forbruger og leverandør i form af sikkerhedstoken Kan brugs til at verificere sender eller modtager af SOAP besked Digital signatur (c) SOA Network,

33 Trusler der beskyttes mod Un-authenticated sender Use tokens and digital signature Unauthorized receiver Use XML encryption Replay Digital signatures alone are not enough to defeat replay. Other parts of the specification must be used with d-sig, such as timestamp, sequence number and nonce. Token Substitution Sign both the security header and the body. Message modification Sign the message Message substitution - Sign both the security header and message body Man-in-the-middle (c) SOA Sign Network, both 2004the request and 65 response