Show simple item record

dc.contributor.advisorSteven R. Lerman.en_US
dc.contributor.authorMao, Tingtingen_US
dc.contributor.otherMassachusetts Institute of Technology. Dept. of Civil and Environmental Engineering.en_US
dc.date.accessioned2008-09-03T14:59:38Z
dc.date.available2008-09-03T14:59:38Z
dc.date.copyright2007en_US
dc.date.issued2007en_US
dc.identifier.urihttp://hdl.handle.net/1721.1/42223
dc.descriptionThesis (S.M.)--Massachusetts Institute of Technology, Dept. of Civil and Environmental Engineering, 2007.en_US
dc.descriptionIncludes bibliographical references (leaves 65-66).en_US
dc.description.abstractThe iLab architecture allows students to execute laboratory experiments remotely through internet. It supports three different kinds of experiments: batched, interactive and sensor-based. The iLab Interactive Experiments architecture includes the following servers and services: the Interactive Service Broker (ISB), the Experiment Storage Service (ESS) and the Lab Server (LS). In addition, students execute interactive experiments by running a Lab Client (LC). In order to support interactive experiments which require scheduled access, the iLab interactive architecture envisions scheduling servers and services which enable students from different campuses to reserve time periods to execute experiments. Since the user side and lab side require different scheduling functionalities, a user-side scheduling server (USS) and a lab-side scheduling server (LSS) are introduced in the iLab Interactive Services to manage reservations. In the first part of this thesis, the philosophy of the scheduling services design and the implementation will be illustrated in detail. In dealing the security issues in the iLab interactive architecture, the complexity of the higher level authentication between iLab processes increases when one considers collaboration between domains. In second part of this thesis, I present a Security Token Service (STS) scheme for using WS-Security to optimize the cross-domain authentication in the iLab interactive architecture. The scheme uses the brokered authentication with a security token issued by the STS. The STS is trusted by the web applications and web services in the iLab interactive architecture to provide interoperable security tokens. A security token is used to convey the credential information and the proof of a relationship with the broker, which can be used by the service to verify the token. A comparison between the STS scheme and the current General Ticket scheme is summarized.en_US
dc.description.statementofresponsibilityby Tingting Mao.en_US
dc.format.extent66 leavesen_US
dc.language.isoengen_US
dc.publisherMassachusetts Institute of Technologyen_US
dc.rightsM.I.T. theses are protected by copyright. They may be viewed from this source for any purpose, but reproduction or distribution in any format is prohibited without written permission. See provided URL for inquiries about permission.en_US
dc.rights.urihttp://dspace.mit.edu/handle/1721.1/7582en_US
dc.subjectCivil and Environmental Engineering.en_US
dc.titleScheduling services and security ticket token services in iLab interactive servicesen_US
dc.typeThesisen_US
dc.description.degreeS.M.en_US
dc.contributor.departmentMassachusetts Institute of Technology. Dept. of Civil and Environmental Engineering.en_US
dc.identifier.oclc230956212en_US


Files in this item

Thumbnail

This item appears in the following Collection(s)

Show simple item record