OpenID

While password authentication is a common web application scenario for user authentication, more recently the concept ofdecentralised authenticationhas become popular, and in particular the OpenID standard [281]. OpenID allows for users to control their own identity verification, and this improves both reliability, security and privacy. Modelling OpenID verification is an important use case48 of Rich Internet Applications.

Web applications that use OpenID do not need to store sensitive personal information like e-mails or passwords in order to perform identity verification, but can instead store a single URL which will independently perform this service. OpenID only handles the verification of identities rather than profile data; this decision was made by design to reduce the scope of the project. The OAuth standard [145] may be utilised to support user profile management.

On a separate level, OpenID authentication can be considered as merely aspecific typeof authenti- cation; other types of authentication include Google Accounts or Microsoft Passport, and it should be simple to include these as separate authentication protocols. Furthermore, it may be possible to unify all these different authentication methods into a single “authentication” datatype, such as the datatype

iamlIdentityproposed earlier in Section5.5.2.

It is important to let the developer decide which types of authentication methods they support, rather than simply assuming that the developer would want all authentication types. For example, OpenID does not provide identity management, and is easier to subvert or modify than a Google Account or a Microsoft Passport identity due to its decentralised nature; consequently there may be some scenarios of authentication where the developer would consider OpenID identity verification as too insecure.

Rationale behind the typeiamlOpenIDURL

Many options were considered in methods of representing OpenID authentication. One option was to define a particular type ofDomain Attributewith anisSecureattribute which would represent authen-

tication attributes. However this would mean OpenID authentication could only apply to instances of Domain Types.

Another option was to define a subtype ofGate– such as anOpenID Gatemodel element – which would restrict access to aScopeif a valid OpenID was not provided to the gate. However this approach is too platform-dependent – this would mean that each separate authentication method would have to have a separateGatesubtype within the IAML metamodel.

The decision was made to extend the existing datatype framework and provide a new derived type named iamlOpenIDURL to represent valid OpenID instances. This meant that much of the existing gates and validation frameworks could be reused; for example, a Gate requiring a valid

iamlOpenIDURL-typedValueinstance is one implementation of the proposedOpenID Gate.

This approach may break an assumption that cast instances can always be recast back to an original type. One can consider this as a digital signature on the instance type; if the signature is lost by converting the instance into a different format, then the digital signature (and consequently validity) of the original instance is lost.

5.11

Scopes

As discussed earlier in Section4.7, the ability to model lifecycle and handle lifecycle events may be a useful technique in the development of RIAs. IAML supports lifecycle modelling by definingscopes

through the abstract model elementScope, and assigning various lifecycle events to these scopes. The scopes in IAML are based on the possible lifecycle layers of Rich Internet Applications [368] discussed earlier in Section4.7.1. EachScopehas different initialisation and storage semantics; for example, anInternet Applicationis accessible to all users, whereas aSessionis only accessible by a single browser instance. Scopesin IAML therefore follow a hierarchy, where oneScopecan contain anotherScope, as illustrated in the class diagram in Figure5.39.

AScopemay contain any number of value instances, including primitive type instances (Values, Section5.5.3) and complex type instances (Domain Iterators, Section5.6.3). The semantics of how these instances are represented, stored and shared across different users form thestorage semanticsof thatScope.

When aScopeis rendered, the lifecycle events for thatScopemust be executed before any ele- ments within the current Scopeare rendered. However, the lifecycle events for any parentScopes– that is, up the scope hierarchy – must be executedbeforethe lifecycle events for the currentScope. This allows for the designer to protect access to children scopes through parent scopes; for example, in order to access aFrame, the current user must first verify their identity through a parentSession.

5.11.1 Internet Application

AnInternet Applicationinstance represents an entire web application, and is consequently the root element of the model (and the indirect parent of all model elements). Because theonInitEventis only ever called once, this event can be used to perform application initialisation, such as registering web services, initialising databases, and so on. The structure of theInternet Applicationmodel element is discussed in further detail later in Section5.14.

5.11 Scopes 141

Figure 5.39: UML class diagram for theScopespackage of IAML

5.11.2 Session

An instance of aSessionrepresents a user session in the web application; that is, a “sequence of Web transactions issued by the same user during an entire visit to a Web site”, as discussed by Cardellini et al. [48, pg. 268]. Because a web application can support multipleSessions, it is possible for a user to possess many session instances at any point in time; this may prevent data leakage, as instances of data remain independent between differentSessions.

5.11.3 Failure Handlers

It is necessary to support the graceful failure of errors in a web application. In IAML, the concept of afailure handleris used as a form of exception handling, and eachScopein the web application has an associated failure handler. In the case of an exception, this failure handler is executed.

An outgoing ECA Rule from a particular Scope with the name “fail” is defined as a failure handler for the given scope. If an error occurs during the execution of the given Scope, then the failure handler for thatScopeis executed according to the semantics of theECA Rule(Section5.4.3). For example, if anOperation executed via an ECA Rulefails, all subsequent Action Edges in the

InternetApplication: ’Ticket 2.0’>Session: ’Manager Session’ !"

Figure 5.40: Ticketiaml: Protecting access to aScopevia an entryGate

ECA Ruleis executed.

If the currentScopedoes not define afailure handler, then thefailure handler of the containing Scopeis used as the failure handler. If an exception is not caught through the containment hierarchy of Scopes, then the exception is caught by the runtime environment and the web application will display a runtime error.

Since exceptions are essentially a form of triggerable event, it may be desirable to instead imple- ment exception handling through the event modelling approach of IAML. This remains future work; for example, an event trigger such as onException could be introduced into the IAML metamodel, using the same failure handler semantics as discussed before.

5.11.4 Gates

One common use case in web application development is to selectively prevent access into portions of the web application, without first obtaining the appropriate permissions. Another is to force a user to view an advertisement before they may proceed with the current page.

In IAML, aGatemay be used to address these scenarios, to restrict access into, or out of, aScope according to some condition. However, a web application developer should useGateswith caution, as web application users may become frustrated if it is too difficult to satisfy a condition of a particular Gate, and simply abandon the web application.

Two types ofGatesare defined. An entryGaterestricts accessintoa givenScope, and will prevent entry until a particularConditionis satisfied. Likewise, an exit Gaterestricts access out of a given Scope, and will prevent exit until a particularConditionis satisfied. The functionality behindGates are strongly dependent on the method in which theScopemay be accessed.

An exitGatecannot actually prevent the user from closing down their web browser, or manually navigating to an external URL. This is a restriction of the current implementation of web browsers. An exitGatemay still be used to prevent any further interaction within the modelled web application.

5.12 Messaging 143

In the Ticketiaml application, an entry Gateis used to implement a role check for themanager

Session. As illustrated in the partial visual model in Figure5.40, thisGatewill fail if the incoming Condition– aPredicatedefined as part of theDomain Iteratorwithin the same session – is not true. Consequently, if a logged-in user tries to access anyFramewithin the protectedSession, they will be redirected to theInvalid CredentialsFrame.

5.11.5 Query Parameter

AQuery Parameter is an extension of the Valuemodel element discussed earlier in Section 5.5.3, and represents a parameter from the current browsers’ URI request. For example, a request URI

target?name=valuewould set the “name”Query Parameter to the value “value”. Conceptually a Query Parameteris different from aValue; theValuebelongs to the containingScopeand persists across calls within that scope, whereas aQuery Parameteris global and is entirely dependent on the request URI. Therefore, it is necessary to have a separate element to distinguish the two.

5.11.6 Discussion

During the design of the IAML metamodel, other model elements within the IAML language were also considered as potentialScopes. AnOperationcould be considered aScope; here, theonAccess

event would be fired whenever the operation is executed. AVisible Thingcould also be considered a Scope, and would follow theonAccessevent semantics ofFrame.

Similarly, a request itself could be modelled as aScope [368], but this would require a precise definition of a user request. For example, can only requests triggered explicitly by the user be consid- ered a request, or would requests via AJAX also be considered a request? Such aScopecould define events for when the request begins, finishes, or is redirected to another URL.

The idea of supporting user-definable scopes was also considered; for example, allowing the de- veloper to specify a “within the administration area” scope, or to designate scopes using tagging. This was not one of the identified use cases of RIAs, and the implementation of this concept should not be difficult as future work. However it is not possible to describe arbitrary events without requiring an event modelling language, as discussed earlier in Section5.4.3.

The IAML metamodel does not define pre- or post-lifecycle events, as these definitions have not proven necessary. For example, an onFinish event for Sessions could be triggered when a Session times out [246, pg. 114]; however, one cannot guarantee this event will ever be triggered.

5.12

Messaging

Messaging refers to the ability to encapsulate content into a form which may be sent from a source to a recipient. Web applications are mostlypull-based; that is, they provide content in response to a request, rather than actively pushing out content (push-based). However, web applications still have a number of ways of pushing out content, even though their underlying implementations may be pull- based. The most common technique is through sending e-mails49_.

Figure 5.41: UML class diagram for theMessagingpackage of IAML

5.12.1 Email

An e-mail ormail message, as defined by RFC 2821 [184], is a message sent from a sender to a receiver through a number of intermediary servers. The message itself has a number of headers and a

bodywhich may be encoded according to MIME [110]. IAML supports the composition and sending of e-mails through theEmailmodel element, the structure of which is represented in Figure5.41.

The Email model element is a wrapper for a number of Values, each representing the various required headers for the e-mail message; and also contains events and operations necessary for sending the actual e-mail, such as the send Operation. TheEmail model element also defines a number of element-specific attributes, which are used as default values if a similarly-namedValueis not present or not set. As anEmailisWireable, its content may be synchronised throughSet Wires.

When anEmailis composed in order for delivery, thebodyof theEmailwill be composed of all containedPropertiesand their values at the time theEmailwas sent. The format of this body may use acustom templateif this template is specified and supported by the language implementation.