Kontekstinhallinnan määrittely versio 2 luonnos Mika Tuomainen

Esitys aiheesta: "Kontekstinhallinnan määrittely versio 2 luonnos Mika Tuomainen"— Esityksen transkriptio:

1 Kontekstinhallinnan määrittely versio 2 luonnos Mika Tuomainen mika.tuomainen@savonia-amk.fi

2 Sisältö  Korjatut virheet  Tarkennukset  Lisäykset / lisäysehdotukset  Jatkokehitys

3 Korjatut virheet  VIRHE: GetItemValues-metodin poikkeuksista puuttuu UnknownParticipant  Tätä ei mukana versiossa 1, eikä myöskään CCOW:ssa tässä metodissa, koska CCOW olettaa ettei ei-turvallisissa yhteyksissä tarvita tunnistusta. Jos halutaan tunnistus, CCOW:ssa käytetään secure-rajapintoja.  TARVITAAN MINIMITASON MÄÄRITYKSESSÄ, JOTTA VOIDAAN TUNNISTAA KONTEKSTITIETOA HAKEVA SOVELLUS, VARSINKIN KÄYTTÄJÄTUNNUSTA HAETTAESSA.  KORJAUS: Lisätty

4 Korjatut virheet  VIRHE: participantCoupon puuttuu GetItemValues-metodin input-parametreista http-viesteissä  KORJAUS: Lisätty

5 Tarkennukset  Kuvaus v1: A akkoskoosta riippuvuus: Subjektin tietojen nimet ja arvot on käsiteltävä aakkoskoosta riippumattomina, ellei toisin ole erikseen mainittu.  Ehdotus v2: huomioidaan vain subjektien nimet, ei arvoja

6 Tarkennukset  Kuvaus v1: Käyttäjäsubjektia ei turvallisuussyistä saa asettaa minimitoteutuksen SetItemValues-metodilla.  Ehdotus v2: Käyttäjäsubjektia ei turvallisuussyistä saa asettaa minimitoteutuksen SetItemValues-metodilla, ellei turvallisuutta ole jollain toteutuskohtaisella tekniikalla varmistettu.

7 Tarkennukset  Kuvaus v1:  Ehdotus v2: Tarkennettu eri ratkaisuehdotuksia käyttäjäkontekstin turvallisuuteen.

8 Tarkennukset  Kuvaus v1: applicationName: sovelluksen nimi. Liittyessään kontekstinhallintaan sovellus tunnistautuu context manager-komponentille nimensä avulla. Sovelluksen nimellä voidaan myös kertoa etukäteen context managerille, mitkä sovellukset voivat osallistua yhteiseen kontekstiin.  Ehdotus v2: ONKO SOVELLUKSIEN NIMEÄMINEN CONTEXT MANAGERILLE VAPAAEHTOISTA VAI PAKOLLISTA? MÄÄRITELLÄÄNKÖ TÄSSÄ VAI TOTEUTUSKOHTAISESTI?

9 Tarkennukset  Kuvaus v1: JoinCommonContext-metodin allreadyJoined-poikkeus: Samalla nimellä (applicationName) varustettu sovellus on jo mukana kontekstinhallinta-palvelussa.  Ehdotus v2: CM voisi sallia myös ”täsmälleen saman nimisten” sovellusten liittymisen, mikä helpottaisi sovellusten kannalta toteutusta (sovelluksen ei tarvitse tietää montako instanssia sovelluksesta jo on käynnissä). JÄTETÄÄNKÖ NÄIN VAI MUUTETAANKO,SITEN ETTÄ MYÖS SAMANNIMISET SALLITAAN?

10 Tarkennukset  Kuvaus v1: participantCoupon-selitys TÄMÄ POIS: Helposti toteutettavissa esim. laskurilla, jota kasvatetaan aina kun uusi sovellus liittyy kontekstinhallintaan.  Ehdotus v2: TARKEMMIN NÄIN: participantCoupon-tunniste on muodoltaan 32-bittinen kokonaisluku, joka on tietotyypiltään long. Tunnisteen pitää olla sovellusta kontekstisessiossa yksilöivä. Nolla (0) ei saa olla arvona.

11 Tarkennukset  Kuvaus v1: TooManyParticipants: Kontekstinhallinta-palvelu ei voi ottaa lisää sovelluksia palveluun  Ehdotus v2: TARKEMMIN NÄIN TooManyParticipants: Jos kontekstinhallinta-palveluun on määritelty maksimi määrä osallistuvien sovelluksien määrälle ja tämä määrä ylittyy.

12 Tarkennukset  Kuvaus v1: TransactionInProgress-poikkeus Kontekstinhallinta-palvelussa on parhaillaan kesken kontekstin tietosisällön muuttaminen jonkun muun sovelluksen toimesta  Ehdotus v2: Poistetaan, ei tarvita.

13 Tarkennukset  Kuvaus v1: ContextNotActive-poikkeus Kontekstinhallintapalvelu ei ylläpidä aktiivista kontekstia. This should be transparent to applications that have a means for handling unexpected exceptions, if in fact this exception is ever encountered. Ehdotus v2: Poistetaan, ei tarvita.

14 Tarkennukset  Kuvaus v1: SetItemValues-metodi  Ehdotus v2: Sallitaanko tyhjien arvojen asettaminen Vai onko se toteutuskohtaista? Missä tarvitaan?

15 Tarkennukset  Kuvaus v1: SetItemValues-metodin BadItemNameFormat-poikkeus  Ehdotus v2: sovellus yrittää päivittää tietoa, jota kontekstinhallinta ei tue Edellytyksenä, että kontekstinhallintaan konfiguroitu sallitut itemNamet (= tukee vain määriteltyjä itemnameja) TARKENNETAANKO MÄÄRITYKSIIN PITÄÄKÖ SALLITUT ITEMIT OLLA MÄÄRITELTY ETUKÄTEEN VAI EI ? JÄTEÄÄNKÖ TOTEUTUSKOHTAISEKSI?

16 Tarkennukset  Kuvaus v1: GetItemValues-metodin itemValues-parametri  Ehdotus v2: Pitäisikö tarkentaa GetItemValuesia myös siten, että jos haetaan item, jota ei ole asetettu, siinä palautuu tyhjä (ei esim. virhettä)? Onko määrityksissä tarpeellista määrittää, että parametrien pitää tulla tietyssä järjestyksessä? Pitäisikö kirjoittaa, että kontekstipalvelutoteutus ei saa olettaa tiettyä järjestystä? Vai, että palautuu siinä järjestyksessä kuin on pyydetty?

17 Tarkennukset  Kuvaus v1: GetItemValues-metodin UnknownItemName-poikkeus  Ehdotus v2: sovellus yrittää hakea kontekstinhallinnasta tietoa, jota ei ole kontekstissa TÄMÄ PITÄISI TARKENTAA NÄIN: sovellus yrittää hakea kontekstinhallinnasta tietoa, jota ei ole asetettu kontekstiin

18 Tarkennukset  Kuvaus v1: 7.5 Http-viestin muodostaminen  Ehdotus v2: muotoon: 7.5 Http-kutsun muodostaminen. Paluuarvoille oma kappale. kts jatkokehitys kohta 2

19 Lisäykset / lisäysehdotukset  Lisäys:  pidempi johdanto kappaleeksi 1  kpl 4.1 Kontekstinhallintaan liittyminen  kpl 4.4 Kontekstinhallinasta eroaminen

20 Lisäykset / lisäysehdotukset  Lisäys: Kpl 6.1 Rajapintojen, metodien, parametrien ja subjektien nimeäminen  poikkeukset (UnknownApplication)  Selitys: Versiossa 1 Rajapintojen, metodien ja parametrien nimeäminen epätarkasti + poikkeukset ONKO KPL 6.1 OK?

21 Lisäykset / lisäysehdotukset  Lisäys: JoinCommonContext-metodin UnknowApplication-poikkeus  Selitys: Kontekstinhallintapalvelu ei tunnista sovellusta. Tilanteessa, jossa kontekstinhallintapalveluun on konfiguroitu sallitut sovellukset etukäteen. LISÄTÄÄNKÖ? VAI PALAUTETAANKO TURVALLISUUSSYISTÄ VAIN GENERALFAILURE?

22 Lisäykset / lisäysehdotukset  Lisäys: SetItemValues-metodin ChangesNotAllowed-poikkeus  Selitys: Sovellus ei saa asettaa tiettyä subjektia, esim. käyttäjä-subjektia minimimäärityksen mukaan. LISÄTÄÄNKÖ MÄÄRITYKSEEN TÄLLÄ NIMELLÄ VAI MÄÄRITELLÄÄNKÖ JOKU MUU?

23 Lisäykset / lisäysehdotukset  Lisäys:  kpl 6.4 Rajapintojen käyttöesimerkki  kappaleisiin 7.6 ContextManager-rajapinta ja 7.7 ContextData-rajapinta esimerkit http-viesteistä ja paluuarvoista  Liite 1. Turvallisuus  Liite 2. Jatkokehitys  Liite 3. Minimitoteutuksen edut ja erot CCOW-standardiin

24 Jatkokehitys  ”Pollaus”  Turvallisuus  Työaseman identifiointi IP:n avulla ongelmana, jos työasemat ovat esim. NAT-osoitteiden takana  http-viestien tarkennus

25 Jatkokehitys – ”pollaus”  ”Pollaus”  Mikäli kontekstinhallinta-palvelu ”kaatuu”, on sovelluksen osattava toimia ilman kontekstinhallintaa. Miten sovellus voi tarkistaa kontekstinhallinta-palvelun toiminnan, muuten kuin saamalla virheilmoituksen palvelimelta kutsuessaan kontekstinhallinta-palvelun metodeja?  Mikäli kontekstinhallintaan liittynyt sovellus ”kaatuu”, muodostuu ongelmaksi kontekstinhallinta-palveluun roikkumaan jäävät turhat sovellukset. Kontekstinhallinta-palvelu mahdollisesti olettaa, että kontekstia pitää vielä pitää yllä, koska kaikki sovellukset eivät ole eronneet kontekstinhallinnasta. Miten kontekstinhallinta-palvelu voi tarkistaa sovellusten olemassa olon?

26 ”Pollaus” – uusi metodi  Miten sovellus voi tarkistaa kontekstinhallinta- palvelun toiminnan?  Yksi ratkaisu esitettyyn ongelmaan olisi määritellä uusi metodi, jolla sovellus voisi varmistaa kontekstinhallinta-palvelun toiminnan. Kontekstinhallinta-palvelu vastaisi metodiin esimerkiksi true/false- mekanismilla.  Tällä metodilla olisi mahdollista selvittää myös istunnon voimassaolo. Sovellus antaisi input-parametrina participantCoupon tunnisteensa, jonka avulla voitaisiin selvittää, onko participantCoupon-tunnistetta vastaava istunto vielä voimassa.  Muita vaihtoehtoja?

27 ”Pollaus” – aikakatkaisu  Miten kontekstinhallinta-palvelu voi tarkistaa sovellusten olemassa olon?  Minimitason kontekstinhallinnan tavoitteena on pitää liikenne yksisuuntaisena eli ainoastaan sovellus kutsuu kontekstinhallintapalvelun metodeja - kontekstinhallinta ei kutsu sovelluksia.  Yksi vaihtoehto on määrittää kontekstinhallintaan aikaleima, johon määritellään kontekstin voimassaolo.

28 ”Pollaus” – aikakatkaisu  Vaihtoehtoja toteutukselle:  Vakio  Sovelluskohtainen  Kontekstikohtainen  Tietokohtainen  Kysymyksiä:  Aikaleiman asettamiseen oma mekanismi?  Aikaleiman asettaminen uudella subjektilla?  Asettaako asiakassovellus aikaleiman?  Tapahtuuko context managerissa sisäisesti (konfiguroimalla)?  Onko asiakassovellukselle vapaaehtoinen?

29 ”Pollaus” – aikakatkaisu  Aikaleima ei kuitenkaan ratkaise sitä ongelmaa, että sovellus kaatumisen jälkeen käynnistetään uudelleen ja se liittyy uudelleen kontekstiin. Tällöinhän kontekstinhallinnan pitäisi ilmoittaa, että kyseinen sovellus on jo kontekstissa.  Muita vaihtoehtoja?  Muita näkökulmia  kaksisuuntaisuus?

30 Jatkokehitys - turvallisuus  Tulevaisuudessa määrittelyn seuraaviin versioihin on mietittävä  löytyykö yhtä yhteistä standardi-ratkaisua turvallisuuden huomioimiseen  nyt luotettu sovellus  SSL?  CCOW-tapa?  vai jääkö sen toteuttaminen toteutuskohtaiseksi

31 Jatkokehitys – työaseman tunnistaminen  Työaseman identifiointi IP:n avulla ongelmana, jos työasemat ovat esim. NAT-osoitteiden takana  Ratkaisuvaihtoehtoja  JoinCommonContextWithIp-metodi  Context Management Registry  Muita vaihtoehtoja?

32 Jatkokehitys – työaseman tunnistaminen  JoinCommonContextWithIp-metodi  Työaseman identifioinnissa ovat ongelmana esimerkiksi NAT- osoitteet, jolloin eri työasemat saattavat näin näkyä kontekstinhallinnalle samana IP-osoitteena.  Yksi ratkaisu käyttää JoinCommonContextWithIp-metodia.  Kontekstinhallinta saisi metodin parametrina työaseman todellisen IP-osoitteen, jolla voisi yksilöidä työaseman.  Kontekstinhallinta-palvelu saisi käyttää työaseman todellista IP- osoitetta vain työaseman yksilöintiin.

33 Jatkokehitys – työaseman tunnistaminen  Context Management Registry (CMR)  CCOW-standardin web/http-määritys määrittelee CMR-rajapinnan  CMR toteuttaa vain yhden locate-metodin, joka palauttaa työaseman käyttämän CM komponentin URL-osoitteen sekä oman tunnisteensa (ip/id) työasemalla sijaitsevasta rekisteristä  voidaan toteuttaa esim. applettina  onko kuitenkin liian monimutkainen minimitoteutukseen?  oma rajapinta  rekisteri työasemalle

34 Jatkokehitys – http-viestien tarkennus  Omat kappaleet seuraaville kohdille:  Yleinen skeema  http GET / POST  viittaus komponenttiin  MIME-header  nimetyt argumentit  rajapinnan nimi  metodin nimi  input-parametrit

35 Jatkokehitys – http-viestien tarkennus  Omat kappaleet seuraaville kohdille:  HTTP-merkkien koodaus  output-parametrit  poikkeukset  merkistö  MUITA TARKENNETTAVIA KOHTIA?

36 Jatkokehitys – http-viestien tarkennus  Yleinen skeema  The general schema for representing CMA methods as HTTP messages is to URL-encode the method name and associated parameters as a non-cached HTTP message.  The authoritative source for URL-encoding is IETF RFC 1738, which can be found at http://www.ietf.org/rfc/rfc1738.txt.

37 Jatkokehitys – http-viestien tarkennus  http GET / POST  All CMA web-based components (e.g., context manager, context agent, etc.) shall be capable of receiving CMA methods encoded as HTTP POST or GET messages. The context manager, which is the only component that communicates directly with an application, shall only send HTTP GET messages to applications.  CMA-compliant web applications shall only need to receive CMA methods encoded as HTTP GET messages, but may send HTTP POST or GET messages to CMA components.

38 Jatkokehitys – http-viestien tarkennus  viittaus komponenttiin  A component reference is represented as a URL. The path for a component (e.g., Context Manager) shall be encoded in the file name portion of the URL, for example: www.mcis.duke.edu/CCOW/ContextManager

39 Jatkokehitys – http-viestien tarkennus  MIME-header  The HTTP MIME header for both request and reply messages shall define the value for the standard Content-Type header using the standard name: Content-Type: application/x-www-form-urlencoded  The header shall also indicate that the message should not be cached. In HTTP 1.0, the Expires header should be set to a time that is earlier than when the request was issued (an arbitrarily early time may be used): Expires: Mon, 01 Jan 1990 00:00:00 GMT  In HTTP 1.1, the Cache-Control header shall be set to indicate that the maximum time that the message should be considered as fresh is zero seconds, and that this information must be respected (the net effect is that messages will not be cached): Cache-Control: max-age=0, must-revalidate

40 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit  Named arguments shall be encoded as an argument name followed by the equal sign character (=) followed by a character-encoded representation of the argument’s value. If the argumement is not the first in the list, then it shall be preceded by the ampersand character (&), for example: &name=value  The order in which named arguments are encoded shall not matter. Applications and components shall ignore any named argument whose name is not recognized. Argument names are not case sensitive. The case sensitivity of argument values is specified in the CMA.

41 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - rajapinnan nimi  The interface name shall be encoded as the first named argument, for example: ?interface=ContextData  If the requested interface is not implemented by the component, then it shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).

42 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - metodin nimi  The method name shall be encoded as the second named argument, for example: &method=SetItemValues  If the requested interface is not implemented by the component, then it shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).

43 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - input-parametrit  The method input parameters as defined in the CMA specification shall be encoded as the remaining arguments using the same names that appear in the CMA.  If a parameter is not recognized by the component, then the component shall ignore the parameter. If a necessary parameter is missing, then the component shall return an HTTP reply header with the standard HTTP response code 404 (Not Found).

44 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - input-parametrit  Data Value Representation  All data values shall be converted to string representations per the following CMA Specification Document Sections: 17.2.7, Character Encoded Binary Data; 17.2.8, Representing Message Authentication Codes, Signatures and Public Keys; Section 17.2.9, Representing Basic Data Types as Strings.  Arrays  Arrays are encoded as a vertical bar (|)-separated list of elements. For example: &itemNames=Patient.Id.MRN.medical_center|Patient.Co.Name &itemValues=123-81283-JMDH-79|Marchant^Kyle^^^^ &contextCoupon=27 &appSignature=0BC12D890913E9C98182808CD00BB983288A81238

45 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - input-parametrit  Null Value  A method input parameter whose value is null shall not have any value encoded. For example: &contextParticipant=  Empty String  A method input parameter whose value is an empty string shall not have any value encoded. For example, a parameter whose value is an empty string and a parameter whose value is an array with two elements, the first of which is an empty string, is shown below: &appSignature= &itemValues=|Marchant^Kyle^^^^

46 Jatkokehitys – http-viestien tarkennus  nimetyt argumentit - input-parametrit  Empty Array  A method input parameter whose value is an array with no elements shall not have any value encoded. For example: &itemNames=

47 Jatkokehitys – http-viestien tarkennus  HTTP-merkkien koodaus  All characters used in representing an argument value (i.e., to the right of the equal sign (=)) shall be encoded per HTTP conventions, defined in IETF RFC 2396, Section 2.4, which can be found at http://www.ietf.org/rfc/rfc2396.txt. A conservative summary of these conventions is as follows:  The ASCII characters ‘a’ through ‘z’, ‘A’ through ‘Z’, and ‘0’ through ‘9’ remain the same.  The space character ‘ ’ is converted into a plus sign ‘+’.  All other characters are converted into the 3-character string “%xy”, where xy is the two-digit hexadecimal representation of the lower 8-bits of the character.

48 Jatkokehitys – http-viestien tarkennus  output-parametrit  Method output parameters are encoded in the body of an HTTP reply message. These parameters are encoded using the same scheme as for encoding input parameters. The HTTP reply header shall include the standard HTTP response code 200 (OK) unless otherwise noted in the interface definitions.

49 Jatkokehitys – http-viestien tarkennus  poikkeukset  CMA-specified exceptions are encoded in the same manner as outputs. However, in lieu of outputs, the exception shall be encoded in the body of the reply message as a pseudo output parameter whose name is exception and whose value is the name of the exception, as follows: exception=ExceptionName  If the exception includes data members, then these members shall be encoded in the body of the reply message following the exception name. These members shall be encoded using a same scheme as for encoding input parameters. If members are encoded, then the first member shall be preceded by an ampersand (&), and subsequent members shall be delimited by an ampersand (&), for example:  LIITE 2 JATKUU  exception=BadItemValue&itemName=Patient.Co.Sex&itemVal ue=G&reason=Must be F, M, O or U  The optional pseudo output parameter whose name is exceptionMessage and whose value is an explanation of the exception may also be encoded in the body of the response message:  exceptionMessage=explanation  This parameter is intended for diagnostic purposes. The content of the explanation is not specified and is implementation-dependent.

50 Jatkokehitys – http-viestien tarkennus  merkistö  CMA methods are mapped to HTTP messages, and may be partially or entirely encoded as part of a URL. URLs are currently required to be in US-ASCII, the character set referred to as ISO-8859-1, according to RFC2396. Therefore, only the ASCII character set shall be used to represent any data that is transmitted as part of a CMA- defined method.  However, it may be necessary to represent the data values for certain CMA method parameters using a local character set (i.e., not US- ASCII). When this is the case, the parameter value may be represented using Unicode (see http://www.unicode.org).  In doing so, each Unicode codepoint within the Unicode string shall be encoded as a two-character US-ASCII string representing the hex value of the Unicode codepoint. Each such two-character string shall be preceded by the percent (%) character to signal the message recipient that the following two characters are to be interpreted as hex value for a Unicode codepoint. The high byte of the Unicode codepoint shall be encoded lexically before the low byte.