Implementing Web Services at UCL

Document Sample
Implementing Web Services at UCL Powered By Docstoc
					   Webservices:
    Implementing webservices at UCL




Author:      Mukta Shetye
Reference:
Date:        8 September 2011
Revisions:   Draft
                           Amendment History


Version   Date          Modified By    Reviewed By     Amendment Details
            th
0.1       27 November   Mukta S                        Initial version
          09
            th
0.2       27 November                  J. Anthony      Amended with comments about
          09                           Rickaby         mobile apps.
            th
0.3       27 November                  Simon Farrell   Review comments.
          09
            th
0.4       06 Jan 10     Mukta S.                       Updated with review comments.

                                                       Added examples of web services
                                                       and case study.
            th
0.5       13 Jan 10     Vidit Taneja                   Section 7: Webservices security

                                                       Section 9: Case study
            th
0.6       20 Jan 10     Mukta S.                       Updated sections 7, 9
            th
0.7       24 Feb 2010   Mukta S.                       Updated section 7 on webservice
                                                       Security
            st
0.8       21 May 2010   Mukta S                        Updated the standard for
                                                       webservice development platform.

                                                       All new developments should be
                                                       deployed on Tomcat servers.




                                                                                          2
                                                 Table of Contents
Introduction ......................................................................................................................... 5
1. Purpose.......................................................................................................................... 5
2. What are Webservices .................................................................................................. 5
   2.1. WSDL ........................................................................................................ 6
   2.2. SOAP ......................................................................................................... 6
   2.3. REST ......................................................................................................... 7

3. SOAP v/s REST ............................................................................................................. 7
   3.1. SOAP ......................................................................................................... 7
   3.2. REST ......................................................................................................... 7

4. Design and Approval Process for Webservices.......................................................... 9
   4.1. Inception ..................................................................................................... 9
   4.2. Governance ............................................................................................... 11
   4.3. Inventory of webservices ................................................................................ 11

5. Deploying Webservices .............................................................................................. 13
   5.1. Tomcat ..................................................................................................... 13
   5.2. Oracle Application Server ............................................................................... 14

6. Versioning ................................................................................................................... 15
   6.1. Major/Minor Versioning for WSDL contracts ......................................................... 15

7. Webservice Security ................................................................................................... 21
   7.1. Glossary.................................................................................................... 22
   7.2. Transport layer security: Flow of communication .................................................... 23
   7.3. Example scenario ........................................................................................ 23
   7.4. Configuration steps ....................................................................................... 24
      7.4.1     High level flow diagram ............................................................................. 24
      7.4.2     Configure application server ....................................................................... 25
      7.4.3     Manage SSL Certificates (server) ................................................................ 27
      7.4.4     Manage SSL Certificates (client) .................................................................. 28
      7.4.5     Modify client code and invoke webservice ...................................................... 29
   7.5. Configuring Mutual Authentication on Apache Web server ........................................ 30

8. Examples of webservices ........................................................................................... 31
   8.1. RoomBooking system ................................................................................... 31
   8.2. Common Timetabling .................................................................................... 32
   8.3. Documentum Notification System ..................................................................... 32

9. Case Study .................................................................................................................. 33
   9.1. System summary and webservices potential ........................................................ 33

Case Study – SiP............................................................................................................... 35

                                                                                                                                      3
  9.2. rl_v_employees ........................................................................................... 35
  9.3. rl_v_honoraries ........................................................................................... 36
  9.4. mv_v_employees ......................................................................................... 38
  9.5. Candidate services ....................................................................................... 39
  9.6    Webservice Design ....................................................................................... 39
  9.6. Other potential webservices ............................................................................ 41

10. Additional Considerations .......................................................................................... 42
  10.1. Load testing of webservices. ........................................................................... 42
  10.2. System integration........................................................................................ 42

APPENDIX A: CREATING AND MANIPULATING KEYSTORES ...................................... 43




                                                                                                                         4
Introduction
This document talks about webservices in general and discusses how they must be
implemented in UCL.
This document also defines the standards that must be followed when developing and
publishing webservices.




1. Purpose
      This document is meant for developers and managers to understand what
      webservices are what is involved in developing webservices and which business cases
      are suitable for developing webservices.
      In addition, this document will define standards that must be followed when
      developing webservices in UCL.


2. What are Webservices
      A web service (also webservice) is defined by the W3C as "a software system
      designed to support interoperable machine-to-machine interaction over a network. It
      has an interface described in a machine-process able format (specifically Web
      Services Description Language WSDL). Other systems interact with the web service
      in a manner prescribed by its description using SOAP messages, typically conveyed
      using HTTP with an XML serialization in conjunction with other web-related
      standards1”


      A webservice can be considered to be an application component, which is self
      contained and is self describing. Webservices can be used by any application
      irrespective of its implementation platform.
      This means that the webservice could be written using C# using.Net framework but it
      can be consumed by a Java application. Or by any other language or framework used
      for implementation.
      The basic webservice platform is XML over HTTP. Thus webservices use XML to
      code/decode data and SOAP as a medium of transport.
      To summarise a webservice is something that is expected to be consumed by an
      autonomous application as opposed to a browser or any other user interface.


      When to use or develop webservices:




1
    http://en.wikipedia.org/wiki/Web_service


                                                                                        5
      When an application needs a piece of well defined functionality, then it makes sense
      to develop a reusable utility that can be used by not only one but many applications
      as many times as needed.

      Web services can help to solve the interoperability problem by giving different
      applications a way to link their data.




                                               2




      2.1.    WSDL
      In a webservice, a WSDL defines the contract. WSDL stands for Web Service
      Description Language.
      This is the contract between the client requesting a service and the provider that
      provides it with the necessary information.
      It is because of this WSDL that there is no dependency between the client and the
      service provider as both are expected to only adhere to the WSDL contract.
      WSDL is written in XML and its purpose is to describe the webservices. One could
      consider it similar to a configuration file, which defines all the bits and bobs that go
      into an application. A WSDL defines the location of this webservice, the operations
      that it provides and the response that it would send back.
      To understand a WSDL document, one must have knowledge of XML, XML schemas,
      XML datatypes and namespaces.




      2.2.    SOAP
      SOAP stands for Simple Object Access Protocol. This is a commonly used protocol for
      communication between a webservice consumer and provider.
      SOAP defines the format for sending and receiving messages over the Internet. SOAP
      being based on XML is completely independent of language and platform.
      SOAP thus provides a way to communicate between applications running on different
      operating systems, with different technologies and programming languages.




2
    http://upload.wikimedia.org/wikipedia/commons/4/4a/Webservices.png




                                                                                                 6
  STANDARD:
  SOAP1.1 should be the standard for development. SOAP1.2 is the latest version
  however; most systems still develop and support SOAP1.1.
  e.g.: Spring-ws 1.5.5 supports SOAP1.1




  2.3.   REST
     REST stands for Representational State Transfer. REST is not a standard, but
     simply an architectural style. REST simply means that each unique URL is a
     representation of some object. You can get the contents of that object using an
     HTTP GET.
     REST is not a standard, but it uses standards like HTTP, XML, and URIs.
     REST full services are categorised by:
                Client server based interaction, pull-based interaction style.
                All requests are stateless.
                All resources accessed are using generic interfaces like HTTP
     Unlike SOAP, REST does not need a specific message format. They are lightweight
     as there is no extra XML mark up information.




3. SOAP v/s REST

  3.1.   SOAP
     Pros:
                Language, platform, and transport independent
                Designed to handle distributed computing environments
                Is the prevailing standard for web services, and hence has better support
                 from other standards (WSDL, WS-*) and tooling from vendors
                Built-in error handling (faults)
                Extensibility

     Cons:

                 Conceptually more difficult, more "heavy-weight" than REST
                 More verbose
                 Harder to develop, requires tools
                 With SOAP there is more overhead in the construction of the method
                  request and with the parsing of the request on the web service
                  end. When you have a web service that is serving thousands of requests
                  a minute or second, that overheard may not be needed.


  3.2.   REST

     Pros:

                                                                                             7
             Language and platform agnostic
             Much simpler to develop than SOAP
             Small learning curve, less reliance on tools
             Concise, no need for additional messaging layer
             Closer in design and philosophy to the Web
             REST full services can be invoked from client side code such as
              JavaScript.

      Cons:

             Assumes a point-to-point communication model, not usable for
              distributed computing environment where message may go through one
              or more intermediaries
             Lack of standards support for security, policy, reliable messaging, etc., so
              services that have more sophisticated requirements are harder to
              develop ("roll your own")
             Tied to the HTTP transport model.




STANDARD: At UCL we develop SOAP as well as REST based services. However
the choice depends on what the service has to offer and the intended clients.




                                                                                         8
4. Design and Approval Process for Webservices

  4.1.   Inception
     When developing a webservice one needs to be sure if it‟s a good candidate for
     being a webservice. Webservice development and maintenance comes with
     additional up front costs and the main candidate for benefit is re-usability.
     Before developing something as a webservice, identify consumers for a web-
     service. Know which other systems would be interested in this piece of
     information. This stage will also help in defining what is known as a Webservice
     schema.
     A schema defines what information will be exchanged between a webservice
     provider and consumer. As part of the requirement gathering phase for a
     webservice, one can identify what core information every consumer needs, which
     information is local to just one system. What security considerations one may
     have to include in their webservices.
     Note: Schemas and WSDLs are independent of the consumer (end client). So the
     consumer could be a browser or a mobile application or a back end application.


     Other requirements could be resilience.
     Some candidates where one may consider developing webservices are as follows:
                1) Re-usable business logic.
                2) Integrating applications at the server side, without the need of
                   any UI. Integration could be for exposing services or data.
                3) When building a web application that reads and writes from a
                   database, implement web services between the controller and the
                   database UNLESS all the following apply:
                           You are updating very few tables and there is no database-
                            side validation or other business logic required.
                           There is only one client that is interested in that
                            information. And it doesn‟t seem likely anyone else would
                            want similar data.
                           Consider timelines for delivery of the project. If the work to
                            develop a webservice is considerably higher than alternate
                            means.
                4) When integrating System A with System B (no UI, mostly no
                   controller) UNLESS
                     There is a reason the integration should not be near-real-time
                     (e.g. end of day General Ledger upload, ETL for data
                     warehousing)




                                                                                        9
4.2.     Governance
   Following are the standards that must be followed when developing webservices.


   1) All Web Services should be document-centric, not remote procedure calls
      (RPCs).
   2) Web Services should reference schemas, not define complex types of their
      own
   3) Schemas should be version controlled in SVN/AllChange.
   4) Schemas and WSDL‟s must include proper versioning.
   5) Schemas should be approved centrally before development starts.
         Approvers:
          I. Conrad Morgan, Management Systems
         II. Simon Farrell, Information Services Division
   6) Web service inventory of WSDL and schemas will be held on the SharePoint/
      Wiki.
   7) Web Service security must be considered, when the webservice publishes any
      sensitive information.
   8) The choice of SOAP v/s REST depends on a number of factors:
             a. If the service is meant for Enterprise Application Integration then
                consider SOAP.
             b. If the service is a candidate to be used in an ESB SOAP based services
                would be the way to go.
             c. If the data exposed is meant to read in a webpage one could consider
                developing REST services.
   9) When developing web services, we will be using mutual authentication over
      SSL whereby the service end-point will also require a security credential from
      the client that is trying to access the web service. This credential will be a
      verified certificate. (See section 7. Webservices Security).
   10) All errors thrown by the service will be SOAP faults. This will also include
       checked exceptions and known invalid values.
             a. To receive additional information for a SOAP fault, add an optional
                element or an attribute to the service request with a flag as debug =
                true
             b. The service should return a SOAP fault with the extended fault
                message.
   11) Any service which performs an update operation or simply posts some data
       should return a value to indicate success or failure.




4.3.     Inventory of webservices
       All webservices that are currently in production will be documented on the Wiki.
       http://wiki.ucl.ac.uk/display/InfoSysISDTechStds/Web+Services
The WSDL and the schema for every webservice can be found at the site above.
At present there are no plans to implement a UDDI, but this could be a
possibility in the future. This Wiki is maintained by Simon Farrell, so if one would
like to add any schema or WSDL, please get in touch with him.




                                                                                  12
5. Deploying Webservices
     All webservices should be deployed on Apache Tomcat servers. As of 19th
     May 2010, all new webservice development should use Tomcat for
     deployment.


  5.1.   Tomcat
                    Webservices that are developed using Spring/Axis2 framework can
                     be deployed in Tomcat.
                    This development style uses Eclipse as the IDE and Spring as the
                     development framework.
                    Spring can be substituted with any other development framework
                     such as Apache Axis2. These frameworks are lightweight and
                     provide good webservice support.
                    Eclipse provides some integration with the frameworks using plug-
                     ins that help in webservice development and deployment.
                    Eclipse Ganymede has built in support for creating webservices
                     using Axis/Axis2, which helps create WSDL from java class and
                     interfaces and likewise create java stubs reading from a WSDL.
     Issue:
              1. With Spring as a framework there is a higher learning curve:
                 understanding the framework, dependent frameworks for
                 marshalling/unmarshalling and the deployment process.
              2. With Eclipse and Axis there are inconsistencies with java code from the
                 WSDL.
                     a. Some issues noted are:
                            i. References to namespaces in schemas. Schemas
                               imported in the WSDL, do not include the namespace of
                               the WSDL.
                            ii. Client code generated from the WSDL is inconsistent
                                from the Request and Response stubs.
              So although axis manages marshalling unmarshalling the process is not
              entirely smooth.




                                                                                        13
5.2.   Oracle Application Server
                Webservice development is fully integrated with toolset in the form
               of JDeveloper as the IDE.
                  Helps in exposing PL/SQL packages as webservices.
                Java stubs and WSDL is auto-generated using the webservice
               wizard.
                A good choice when the whole software development and
               deployment stack is Oracle.
                Management Systems currently uses OC4J for webservice
               deployment.
                           o   Note: There is an outstanding issue with security in
                               oC4J. Also note that there are plans to migrate to
                               Weblogic when available. Jdev11g uses Weblogic as the
                               application server.


   Issue:
            Development using an IDE provided by the J2EE application vendor may
            limit one‟s flexibility when it comes to Java Web services as it hides many
            of the details of developing and deploying a Web service.


            Stronger tie-in of the webservice implementation with the underlying
            deployment platform. Thus if one wants the webservice to be deployed on
            a range of application servers, this may not be a simple migration.
            However, if there are no plans for the webservice to support cross
            platform application servers, then it is not much of a problem.




                                                                                     14
6. Versioning
  When developing web services one must version control and add versioning
  information to the schema and the WSDL generated.
  The versioning style proposed supports the evolutionary deployment of services with
  both incremental and major updates.
  The style has been adopted from http://blogs.iona.com/sos/20070410-WSDL-
  Versioning-Best-Practise.pdf.



  6.1.   Major Versioning for WSDL contracts
     Major Versioning is used to accommodate change.

     • A major change indicates a large update that creates an incompatibility with
     existing deployments. Major changes typically indicate large-scale revisions of the
     product, with significant new features and bug fixes.

     • A minor change, that is, a change to second and subsequent digits, indicates an
     update that is backwards compatible with existing deployments of the software
     that share the same major version. Minor revisions typically contain a number of
     small new features, bug fixes and issue resolutions that do not break
     compatibility. Minor change will be included in the comments section of the
     WSDL/schema. No minor number to be included in the namespace or the name of
     the file.

     WSDL versioning is meant to migration of service across various clients, so that
     we do not break backward compatibility. Versioning is not meant for versioning
     the content of the service. Thus, we version the WSDL/ Schemas when we have
     multiple clients accessing different versions of the service, so that we can
     successful avoid conflicts.



     Follow the guidelines below when writing your webservices:


     1. The service specific schema file will be included in the WSDL. The service
        specific schema may include additional schema files.

     2. Do not use the words “wsdl” and “xsd” in the name of the WSDL or the
        schema file.

     3. All optional elements added to the service contract do not need a major
        number change. Only major minor no added to the comments section of the
        service. This is true for operations too.

     4. The service will maintain the same namespace and filename for any minor
        change.


     5. Place the major version number in the WSDL target namespace, and in the
        name of the WSDL file.


                                                                                     15
<wsdl: definitions name="estatesFacilitiesRoomBookingsService_V1.wsdl"
          targetNamespace="http://ucl.ac.uk/isd/cmis/roombooking_V1" >

By encoding only the major release number in the namespace, successive minor
releases share the same namespace and so are compatible.

6. Version the XML schemas using only major version number.

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:cmis="http://ucl.ac.uk/isd/cmis_V1/"
elementFormDefault="qualified"
targetNamespace="http://ucl.ac.uk/isd/cmis_V1/">
       <<Simple/Complex Types>>
</xs:schema>


7. The data-types a service uses should always be placed in separate .xsd files,
   with their own namespaces, rather than bundled in the types section of a
   WSDL document where they can become cluttered and confusing.

<wsdl:types>
      <schema
      targetNamespace="http://ucl.ac.uk/isd/cmis/roombooking_V1.0"
      xmlns="http://www.w3.org/2001/XMLSchema">
      <include schemaLocation="../xsd/roomBookingsServiceSchema.xsd"/
      </schema>
</wsdl:types>

8. Encode major version in the target namespace of the WSDL <types> section.
   As the data-types used by WSDL interfaces should be versioned separately.
   The WSDL contract typically imports or includes these data-types for use in
   the definition of wrapped-doc-literal wrapper elements for each operation‟s
   messages. This helps in keeping track of incremental major changes to an
   interface.

   <wsdl:types>
      <schema
      targetNamespace="http://ucl.ac.uk/isd/cmis/roombooking_V1"
      xmlns="http://www.w3.org/2001/XMLSchema">
      ….
   </wsdl:types>


9. Embed major version in the interface (portType) name.
   Create an explicit interface (portType) for each version of an interface,
   embedding the major number in the interface. The interface name is mapped
   to the service endpoint interface in a destination language; by making the
   interface version explicit we allow the same code-base to implement different
   versions of the same interface.

   <wsdl:portType name="estatesFacilitiesRoomBookingsService_V1">
             <wsdl:operation name="GetBookableSpaceforSearch_V1">
                   <wsdl:input
                   message="tns:GetBookableSpaceforSearchRequest_V1"/>
                   <wsdl:output
                   message="tns:GetBookableSpaceforSearchResponse_V1"
                   />

                                                                               16
             </wsdl:operation>
</wsdl:portType>

10. Embed major version in the service name. This follows the practise of using
    the same name for the service as that used for the interface.

<wsdl:service name="estatesFacilitiesRoomBookingsService_V1">
              <wsdl:port
              binding="tns:estatesFacilitiesRoomBookingsServiceSoap11_V1"
              name="estatesFacilitiesRoomBookingsServiceSoap11_V1_0">
              <soap:address
              location="http://localhost:8080/resourceScheduling/services/" />
              </wsdl:port>
</wsdl:service>


11. Consider a case, when we want to change a service that breaks backword
   compatibility
      e.g: GetBookableSpaceforSearchRequest.

       a. This same service is being used by two clients. Client A is ready to
          adapt to the change to the service. However, client B cannot migrate
          to this changed service for next couple of months.
       b. A change in service contract implies change in client code that makes a
          call to the webservice.
       c. In such a scenario, we must update the version of the schema and
          reflect the version number in the operations defined in the WSDL.
       d. This helps two clients‟ reference two different versions of the same
          web service at the same time without resulting in any conflicts.
       e. In this case we will have a new schema with namespace
          http://ucl.ac.uk/isd/cmis/roombooking_V2. This schema will include
          the changes for the service GetBookableSpaceforSearchRequest.


   <schema targetNamespace="http://ucl.ac.uk/isd/cmis/roombooking_V2"
                   xmlns="htp://www.w3.org/2001/XMLSchema"
      xlns:cmis="http://ucl.ac.uk/isd/cmis_V1/">

       <element name=" GetBookableSpaceforSearchRequest">
       </element>

       </schema>

As WSDL1.1 does not support inheritance or aggregation of interfaces, we must
copy in the operations from previous minor versions of the interface. This will
change in WSDL2.0, when interface inheritance will be supported.

With Spring webservices 1.5.5, only WSDL1.1 is supported.

<wsdl:portType name="estatesFacilitiesRoomBookingsService_V1">
             <wsdl:operation name="GetBookableSpaceforSearch_V1">
                   <wsdl:input
                   message="tns:GetBookableSpaceforSearchRequest_V1"/>
                   <wsdl:output
                   message="tns:GetBookableSpaceforSearchResponse_V1"
                   />
             </wsdl:operation>


                                                                                  17
    </wsdl:portType>


    <wsdl:portType name="estatesFacilitiesRoomBookingsService_V2">
                 <wsdl:operation name="GetBookableSpaceforSearch_ V2">
                       <wsdl:input
                       message="tns:GetBookableSpaceforSearchRequest_ V2"/>
                       <wsdl:output
                       message="tns:GetBookableSpaceforSearchResponse_ V2"
                       />
                 </wsdl:operation>
    </wsdl:portType>

    12. Create a new service for each version of an interface.

    <wsdl:service name="estatesFacilitiesRoomBookingsService_ V2">
                  <wsdl:port
                  binding="tns:estatesFacilitiesRoomBookingsServiceSoap11_V1"
                  name="estatesFacilitiesRoomBookingsServiceSoap11_V1">
                  <soap:address
                  location="http://localhost:8080/resourceSchedulingRBS/services/"
                  />
                  </wsdl:port>
    </wsdl:service>


    <wsdl:service name="estatesFacilitiesRoomBookingsService_V2">
                  <wsdl:port
                  binding="tns:estatesFacilitiesRoomBookingsServiceSoap11_ V2"
                  name="estatesFacilitiesRoomBookingsServiceSoap11_ V2">
                  <soap:address
                  location="http://localhost:8080/resourceSchedulingRBS/services/"
                  />
                  </wsdl:port>
    </wsdl:service>


    Both services share the same endpoint/address information. The service endpoint
    can now accept messages from clients using both version 1.0 and version 2 of the
    interface.

    13. The schema file for the service and the WSDL will share the namespace. The
       schema file for the service may in turn include many other schema files.




    Recap


•   XML schemas will use major only version scheme.


•   WSDL files will include major only scheme.
       –    Any significant structural change to the schema will mandate a major
            version change.
               •   Thus being reflected in a major version change to the WSDL.


                                                                                   18
–   Any elements added as optional will not need a version change in the XML
    schema and the WSDL.




                                                                          19
14. All WSDLs and schemas are being maintained on the Wiki
http://wiki.ucl.ac.uk/display/InfoSysISDTechStds/Webservices-Usage+Statistics

Here you can see a table which must be updated for every webservice in
production.
Table includes:
            Webservice name
            Version number
            Created/Updated date
            Webservice owner (Name-email)
            Consumer applications (List of all clients that call this webservice)
            WSDL version used (WSDL version referred by the clients)
            Date since use (Date from when the client refers to the service- Go
              Live date)
            Consumer application contact (Name-email)
In the Attachment tab you can find all the production webservices and the
schemas.

15. The Wiki can also be used to write about potential candidate webservices.
      a. If there is a system to system communication that needs to be
         enhanced then one could consider developing a webservice
      b. Candidates could be materialised views, batch scripts, db links that are
         used to cross system communication.
      c. Any webservice development must always be estimated.




                                                                                20
7. Webservice Security
One must ensure webservice security for the reasons below.

      Confidentiality and integrity of data that is transmitted via Web services protocols
       in service-to service transactions.

      Functional integrity of the web services requires establishment of trust between
       services on a transaction-by-transaction basis.

One needs to secure webservices because SOAP transmitted over HTTP is allowed to flow
without restrictions through firewalls.

Webservice security can be implemented using either Message Level security or
Transport level security.


       Transport Level Security                     Message Level Security




      SSL connection is established            The XML message itself is digitally
       between each pair of                      encrypted.
       communicating end-points.                The security credentials are passed
      The message is passed over                in the SOAP header.
       this secure connection.                  Usually used in addition to
      Faster as compared to Message             TLS/SSL.
       Level Security.                          Issue: CPU intensive, complex to
      Issue: Using Transport Level              deploy
       security, one cannot ensure
       that the message will remain
       secure in scenarios where
       intermediary(s) are involved.


We will use transport layer security for these two primary reasons:

      The current webservices related scenarios at UCL do not involve multiple
       intermediaries
      Message layer security is complex to deploy and highly CPU intensive.

When developing webservices, we will be using mutual authentication over SSL
whereby the service end-point will also require a security credential from the



                                                                                          21
client that is trying to access the web service. This credential will be a verified
certificate.


   7.1.   Glossary
          A brief description of the most commonly used terms with digital
          authentication:
                 Certificate: A certificate is an electronic document that identifies and
                  authenticates a person / application / server during a communication
                  between two end-points over SSL. A certificate, signed by a
                  Certification Authority (CA), contains the identity information and the
                  public key. The private key is secretly held by the end user.
                 Truststore: A truststore contains all the public key certificates of the
                  CAs or entities that the machine trusts and intends on communicating
                  with.
                 Keystore: A keystore is a database of an entity‟s private keys. It is
                  primarily required on the server, but also on the client side if the
                  server requires client authentication. In Java, a keystore can be
                  created and manipulated using a java utility called keytool.
                  NOTE: A keystore and truststore can be the same (i.e. a keystore
                  can contain trusted certificates as well) for better manageability
                  purposes.
                 Mutual authentication: This is a dual authentication process where
                  not only the server needs to be authenticated but also the client
                  machine that requests any information. This is usually done when the
                  client is requesting the server for confidential information. The server
                  provides its digital certificate to the client and the client presents its
                  certificate to the server over SSL.
                 Root certificate: The top-most certificate in a chain of certificates is
                  called a root certificate. A root certificate is required because at times
                  the server certificate is not in the client's truststore. In this case the
                  client will check for the CA of the server certificate and see if the CA's
                  certificate exists in the client's truststore. If this CA is also not
                  recognised then it will check the CA of the next level and so on, until
                  it recognises a CA. The certificate of this particular CA is the root
                  certificate.




                                                                                          22
     7.2.          Transport layer security: Flow of communication


                           Client truststore                                                       Server truststore




                                                                                                      Client.cert
                               Server.cert




 3. Verifies certificate                                                                                               5. Verifies certificate




                                                            1. Request protected resource


                                  Client                        2. Present certificate                  Server

                                  Client.cert                                                  Server.cert
                                                                4. Present certificate


                                                               6. Continue communication


        NOTE: As can be seen in the illustration above, the Server truststore should
contain the client‟s certificate, and the client‟s truststore should contain the server‟s
certificate.




     7.3.          Example scenario
                 In order to test the different options available to us in terms of Application
              Servers/IDEs/frameworks, we used the following setup (as mentioned earlier,
              any language/server can be used when implementing webservices. The setup
              below is just an example):




     Webservice consumer                                                                    Webservice provider
                                                                                                                               To retrieve
                                                    getPersonDetailsRequest(UPI)
                                                                                                                               details based on
                                                                                                                               UPI


                                                           SOAP

                                                                                                                                        UPI
                                             GetPersonDetailsResponse (firstName, surname)


              IDE: Eclipse                                                                   IDE: JDeveloper
              WS Framework: Axis2                                                            Server: OC4J
              Server: Tomcat 5.5                                                             WS source: Created from
                                                                                             existing Oracle package


                                                                                                                                           23
       NOTE: Both provider and customer are running on the same local machine


7.4.     Configuration steps
         In this section, we will look at the step-by-step procedure to enable mutual
         authentication for OC4J.


         Assumption: The server has a signed (trusted) certificate which is presented
         to all clients that access the server on SSL (https port).
         NOTE: The webservice has already been generated from the oracle package
         and deployed on OC4J.



         7.4.1        High level flow diagram


Configure application server                         Manage SSL certificates (server)
    a) Set SSL port                                      a)   Generate server certificate
    b) Set keystore details                              b)   Get it signed by root CA
    c) Set client authentication = true                  c)   Install it on the server
                                                         d)   Copy root CA cert to client
                                                              environment.




                                                     Manage SSL certificates (client)
Modify client code and invoke webservice
                                                         a)   Generate client certificate
    a)   Specify client side keystore when
                                                         b)   Get it signed by root CA
         making the call to the service
                                                         c)   Install it
                                                         d)   Copy root CA cert to server
                                                              environment.




                                                                                            24
 7.4.2      Configure application server

 By default, servers are not configured to ask for client authentication (i.e.
 request client certificate).
 Since our server side code is deployed on OC4J, here are OC4J specific
 configuration steps:


 I. Go to the <<JDeveloper installation>>\j2ee\home\config folder
 II. If you don‟t have a secure-web-site.xml file, it means that your OC4J
     installation is not yet configured to use SSL port
III. Create a file called secure-web-site.xml and copy the contents from
     default-web-site.xml
IV. Under the main <web-site> element, add the port number and set
    “secure”=true:
     <web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas
     /schema/web-site-10_0.xsd” port="4443" secure="true" display-
     name="OC4J 10g (10.1.3) Secure Web Site" schema-major-
     version="10" schema-minor-version="0" >


 V. Add a new element <ssl-config>. It should look like:
     <ssl-config
     factory="com.evermind.ssl.JSSESSLServerSocketFactory"
     keystore="server.keystore" keystore-password="serverkeystore"
     needs-client-auth="true"/>
            i)     Keystore: write the name of your server‟s keystore here.
                   This keystore will contain the trusted certificates and the
                   client‟s root CA certificate. (See APPENDIX A )
            ii)    Needs-client-auth: Should be set to true if the server
                   wants a valid certificate from the client before proceeding
                   with the communication.


 If your application had already been deployed on non-ssl port (default-web-
 site.xml), you should have an entry defining your application name and root
 (the element name is <web-app>.
VI. Edit the “shared” attribute and change the value to “true” in both the
    files: default-web-site.xml and secure-web-site.xml.
   e.g.:
   <web-app application="uws-uws-WS" name="WebServices" load-on-
   startup="true" root="/uws-uws-context-root" shared="true" />

 The above setting means that the application can be accessed both on http
 and https. If you want that the application be accessed only via http, remove
 the above entry from default-web-site.xml

VII. Open the server.xml file.
     Look for “<web-site default="true" path="./default-web-
     site.xml"/>


                                                                                 25
VIII. Change this to “<web-site default="./default-web-site.xml"/>
 IX. Also add the line: “<web-site default="./secure-web-site.xml"/>




                                                                       26
7.4.3      Manage SSL Certificates (server)


   I. Create a keystore using keytool command.
           a. In sample above,
           PATH = <<Your JDeveloper installation>\j2ee\home\config
           folder>>
              D:\Software\JDeveloper\j2ee\home\config\keytool –
           genkey –alias server –keyalg RSA –keystore
           server.keystore [return]
        The tool will prompt with questions that must be answered when
        creating the keystore.
        NOTE: If the server.keystore does not exist already, it will be
        created. A password prompt will be provided for keystore. Make sure
        you enter the same password as entered in the secure-web-site.xml.
        NOTE2: You will also be prompted to enter a password when creating
        a new „alias‟. Make sure that you enter the same password as for the
        keystore.


  II. Export the self-signed certificate using the following command
      (although we are using a self-signed certificate here, it is always a
      good idea to get the certificate signed using
           keytool –csr… (See APPENDIX A)
           D:\Software\JDeveloper\j2ee\home\config\keytool –export –
           alias server –keystore server.keystore –file
           oc4jserver.cer [return]


        Enter the password for the keystore. The file oc4jserver.cer will be
        created in the current directory.


 III. Copy the file oc4jserver.cer to the client‟s truststore folder. In our
      case, the client‟s truststore is:
      <Java_home>\JRE\lib\security\cacerts
 IV. Change the command prompt to the above folder
  V. Import the oc4jserver.cer certificate into the truststore (cacerts):
        D:\Program Files\Java\jdk1.6.0_11\jre\lib\security\keytool –
        import –alias server –keystore cacerts –file oc4jserver.cer
        [return]
        When it asks for the password, enter the default password
        „changeit‟.
  The server‟s certificate is now a trusted certificate on the client
  environment.




                                                                               27
7.4.4     Manage SSL Certificates (client)

  The same steps as above can be repeated for the client side certificate as
  well.
   I. Let‟s suppose that the client keystore in the above step was created at
      path:
    D:\Program
    Files\Java\jdk1.6.0_11\jre\lib\security\client.keystore
    And the client certificate file is tomcatclient.cer. As with
    server‟s keystore (7.4.3) make sure that the passwords for
    the client‟s keystore and any aliases(keys) under that
    keystore are the same.
  II. Copy the client certificate file to the server‟s truststore. In this
      example, the server‟s truststore is under oc4j‟s config folder:
      D:\Software\JDeveloper\j2ee\home\config\server.keystore
 III. Import the tomcatclient.cer certificate into the truststore (cacerts):
  D:\Program Files\Java\jdk1.6.0_11\jre\lib\security\keytool –
  import –alias client –keystore server.keystore –file
  tomcatclient.cer [return]
  Enter the password when prompted to do so.
  This will be the same password as you defined in the secure-web-
  site.xml file.


  With this, the client‟s certificate will be added to the server‟s truststore
  and server‟s certificate added to the client‟s truststore.




                                                                                 28
7.4.5      Modify client code and invoke webservice


The only step remaining now is to modify the client code before making a call
to the webservice. Since the server is going to request for a client certificate,
we need to set the client‟s keystore details in the System properties. See the
following code snippet:


public static final String KEYSTORE_PRIV_FILE =
“D:/Programiles/Java/jdk1.6.0_11/jre/lib/security/client.keystore"
;
public static final String PASSWORD_PRIV_FILE = "clientkeystore";

System.setProperty("javax.net.ssl.keyStore", KEYSTORE_PRIV_FILE);
System.setProperty("javax.net.ssl.keyStorePassword",PASSWORD_PRIV_
   FILE);

If you wish to see the SSL communication in your console, you can set the
following property:

 System.setProperty("javax.net.debug", “ssl”);

Of course, if the client and server are on a separate machine, there will be a
slight difference in the above steps (difference in truststores).

Apart from keytool, openSSL can also be used to generate certificates and
certificate signing requests.
More information on openSSL can be found at: http://www.openssl.org/




                                                                               29
    7.5.     Configuring Mutual Authentication on Apache Web server


This section is based on the document written by Mauro Ballabio from Management
Systems.



  D:\MuktaS\UCL
WorkItems\Show and Tell\WebServices\TestingMutualAuthentication.doc



The idea here is configure mutual authentication only for specific applications on the
Apache web server. There could be a case that many applications are deployed on
Apache but only a few are in need for client side authentication.
The document attached defines configuration steps on Apache to enable selective project
client side authentication.




                                                                                         30
8. Examples of webservices

  8.1.   RoomBooking system
            EFD RoomBooking system uses a web application that allows users to
            request room bookings online.
            Two of the main features of this site are that it allows users to view a list
            of the centrally bookable rooms available in the current academic year.
            And secondly it allows users to search for rooms in the current academic
            year for a given date and time.
            Both these requirements require the application to query the CMIS data.
            Since CMIS room booking data could potentially be used by more than one
            application it made sense to develop two webservices that provides this
            data to the web application.
            RoomBooking system exposes two webservices.
                       i. GetAllBookableSpaceRequest
                       ii. GetBookableSpaceforSearchRequest


            GetAllBookableSpaceRequest:
                   This service provides a list of all the centrally bookable rooms for
                   the current academic year.


            GetBookableSpaceforSearchRequest:
                   This service expects the client to send the date, start and end time
                   range. Bases on the inputs all the available rooms for the said date
                   and time are returned.


     Any external system that needs booking information can call this service and
     process further.
     At the moment only the RoomBooking webapplication makes use of these
     webservices.




                                                                                          31
8.2.   Common Timetabling
   Common Timetabling web application queries CMIS to display timetabling
   information for students, staff, staff who are also students, departments and
   degree programs.
   These timetables of various groups of users are exposed as webservices.
   Common Timetabling exposes 5 webservices.
   1. GetEventsForStudentRequest
   2. GetEventsForStaffRequest
   3. GetEventsForModulesRequest
   4. GetEventsForRouteRequest
   5. GetEventsForDepartmentRequest


   Each of these services returns a list of events for different groups of users such as
   students, staff, modules, route and department.
   These services are consumed by the common timetabling web application.
   In addition to the web application, there is a new project underway that will
   display the timetable in an iPod application.
   This mobile application will be making use of these webservices to show the
   timetable data.
   These services made good sense to be exposed as webservices as more than one
   client (desktop/hand held devices) can now easily call these services to display
   timetable data.


8.3.   Documentum Notification System
   SITS team is currently developing a Documentum notification system. This
   webservice is about sending out notifications from Documentum to any third
   party system that is interested in changes to Documentum records.
   This webservice is being developed for the SDS (Student Disability System)
   project that uses Documentum to hold documents about students, applicants and
   enquirers. Any changes to documents that SDS is interested in will be notified by
   Documentum to SDS.
   These changes will now be notified to SDS using a webservice instead of
   developing a db link.
   Although this webservice at present focuses on SDS related information, the
   schema designed is generic and can easily be extended to provide notification to
   any other system.




                                                                                     32
9. Case Study




The user provisioning process in UCL is a good model for a potential set of webservices.
However, the process is currently being understood in complete detail before arriving at
a conclusion about the set of webservices.



   9.1.   System summary and webservices potential
            I. SITS, HR and Services systems are primary systems that are responsible
               for the initiation of the user provisioning for students, staff and visitors
               respectively.
           II. UPI consolidates data in primary systems with the use of views and
               tables of its own. It acts as a holding point for data from primary
               systems and IS systems (user provisioning data).
           III. The process above results in the generation of userid and email for a
                new user. However, owing to the usage of overnight pull-based batch
                scripts, this provisioning is completed only after 2 days of the initiation
                at the primary system level.
           IV. Through this case study, we will evaluate the possibility of having
               createUserid & createUserEmail as webservices that can be invoked
               by the primary systems.
            V. However, it is too early to conclude on the feasibility of such webservices
               since the impact of change on primary systems has to be evaluated as
               well.
       Please comment on the scope of this case study exercise. When talking about
       creating these webservices we would have to consider:
       1) Feasibility/Impact Analysis?
       2) Which operation in the above diagram do we analyse?

                                                                                          33
       3) What is the expected outcome from this case study?
              a. Schema?
              b. WSDL?
              c. End clients to this webservice?


After discussion with Vidit/Conrad/Anthony it‟s decided that User Provisioning will not be
considered for the Case study. There is an ongoing analysis of User Provisioning and
Identity management which is looking at how the present system works and its pitfalls.
At the end of this analysis its to be decided the system should be re-designed or
replaced by a COTS like application.
As this case study may not be useful, it would be better to consider an alternate system
for the Webservices Case study.




                                                                                        34
Case Study – SiP

SiP is a standalone Oracle forms application that resides on the GEN database and
served through the 10g application server on as02. The application is a workflow process
for starters, leavers and one off payments. The system is used by Departmental
administrators who use this application to draw up contracts for new joiners, change in
employment contracts, and change in pay scale and leaver‟s information.
Information in SiP is drawn from the ResourceLink application which is the core HR and
Payroll system. Data that is referenced in SiP such as several lookups in the application
gets picked up from ResourceLink. Data interfaces with ResourceLink are either via
Views or daily data dumps taken to populate the SiP datastore.
Also data entered in SiP most times is replicated again in ResourceLink as there is no
means to refresh ResourceLink from SiP. On an average about 70% of data gets
replicated between SiP and ResourceLink.


The purpose of this case study is to identify candidate webservices for HR systems,
which could be used by a host of applications that fetch HR data.
At present most of the data exchange is using view on database links. Views written are
intended for specific host applications. When a new system requests HR data, a new
view gets written where most of columns are similar to existing views. The problem here
is duplication and maintenance overheads.


For this case study we have considered only two systems SiP and DAM which use HR
data from ResourceLink. Both these systems have read-only interactions from
ResourceLink. I.e. data is only read from ResourceLink, but no data is updated on
ResourceLink.
Views from the ResourceLink system provide employee information and their payroll
information, which gets used across both SiP and DAM.
For example information like employee number, name, post start and end dates,
designation , department, staff type get repeated across views even for the same
system.




    9.2.    rl_v_employees
View Name             rl_v_employees

                      View providing all employees.
                      The view does not include
                      Hon records.

Columns                                               Notes

employee_number       Text                            D550M.employee_number

surname               Text                            D500M.surname

forename              Text                            D500M.first_forname

Title                 Text                            D500M.title

post                  Text                            D200M.post_number




                                                                                         35
post_start_date        Date                         D580M.start_date

post_end_date          Date                         D580M.end_date

main_post              Char                         D580M.main_flag

department_id          Number                       D117M.str_ref

department_code        Text                         D100M.id

department             Text                         D100M.long_desc

end_date               Date                         D550M.end_date Left UCL

staff_type             Char                         N = not suspended same as being
                                                    blank
                                                    Y = suspended, not processed in the
                                                    current cycle
                                                    T = means process if a temporary pay
                                                    element exists i.e casuals
                                                    D550M.suspended_flag

dob                    Date                         D500M.birth_date

known_as               Text                         D500M.known_as

ni_no                  Text                         D500M.ni_no

sex                    Char                         D500M.sex

upi_no                 Text                         D501M (via function
                                                    find_upi_no_ucl)

apt_title              Text                         D970M (via function
                                                    find_apt_title_ucl)

projected_end_date     Date                         D580M




      9.3.   rl_v_honoraries
View Name            rl_v_honoraries

                     View providing Hon records.
                     Identified by emp number
                     starting with N or Occupancy
                     type like HON

Columns                                             Notes



                                                                                           36
employee_number      Text                             D550M.employee_number

surname              Text                             D500M.surname

known_as             Text                             D500M.known_as

forename             Text                             D500M.first_forname

title                Text                             D500M.title

dob                  Date                             D500M.birth_date

sex                  Char                             D500M.sex

department_id        Text                             D100M.id

department_code      Number                           D117M.str_ref

department           Text                             D100M.long_desc

end_date             Text                             D550M.end_date

staff_type           Date                             D550M.suspended_flag
                                                      N = not suspended same as being
                                                      blank
                                                      Y = suspended, not processed in the
                                                      current cycle
                                                      T = means process if a temporary pay
                                                      element exists i.e casuals




Here HR has created two views which share the same columns, but as the name
suggests the data will be different in both these views. The first is a list of all employees
the later only honoraries.


If there were a webservice from HR that gave back a list of employees of a particular
type or category. HR only needs manage its business logic at one place, and not create
copies of different views based on different types of employees.


If we look at the some of the views created by HR for DAM, where DAM is a reporting
application written in Oracle Forms and Reports. It provides a standard set of reports to
departmental users. The departmental user will only have access to employees relating
to his/her department. The application is hosted on the GEN database and served
through as01.




                                                                                             37
      9.4.   mv_v_employees


View Name             mv_v_employees

                      View obtaining employee
                      information according to the
                      department the user has
                      access to.

Columns                                              Notes

employee_number       Text                           D550M.employee_number

person_ref            Text                           D500M.person_ref

upi                   Text                           D501M (via function
                                                     find_upi_no_ucl)

title                 Text                           D500M.title

first_forname         Text                           D500M.first_forname

surname               Text                           D500M.surname

known_as              Text                           D500M.known_as

other_forenames       Text                           D500M.other_forenames

initials              Text                           D500M.initials

birth_date            Date                           D500M.birth_date

ni_no                 Text                           D500M.ni_no

sex                   Char                           D500M.sex

honours               Text                           D500M.honours

work_tel_no           Text                           D500M.work_tel_no

home_tel_no           Text                           D500M.home_tel_no

mobile_number         Text                           D500M.pers_tel_mobile_no

email_address         Text                           D033M.email_address

ucl_orig_start_date   Date                           D550M.orig_start_date

orig_how_joined       Date                           D550M.orig_how_joined

ucl_start_date        Date                           D550M.start_date

how_joined            Text                           D550M.how_joined

ucl_end_date          Date                           D550M.end_date

leaving_reason        Text                           D550M.leaving_reason

retire_date           Date                           D970M(via function
                                                     get_retirement_date_ucl)




We once again have HR data passed repeated in views where employees are only one‟s
in a given department.

                                                                                 38
Overall, information about an employee and their department gets repeated almost in
every view in SiP and DAM systems.




   9.5.   Candidate services
             a. Get detailed employee information based on employee number. Some
                of the details that the service could pass back are as:
                      -   The service must bring back, employee number, first_name,
                          known_as, last_name, surname, date of birth, sex,
                          ni_number, department details.
                      -   Department details to include, department id, department
                          name.
                      -   Contract details (post start date, end date, designation)


             b. Get employees belonging to a department.
             c. Get employees of a certain type (honorary, non-honorary..etc?)




   9.6    Webservice Design
             As SiP and DAM are Oracle form applications, and users use these systems
             to constantly deal with employee data, it would not be wise to keep calling
             the webservice for the system functioning in terms of calling the
             webservice to bring all the HR data.
             So the webservice will in this case should be used in the push rather than
             a pull approach.
             The downside is SiP and DAM has to maintain the data that it draws from
             HR in its own data-store rather than relying on views.
             SiP and DAM will have their own tables that will be populated by the
             webservice, when there is a change to an employee record in the master
             tables in HR. This will ensure that the data is real-time and in sync with
             the core system.


             In addition to SiP and DAM there are other systems like Total Rewards that
             also uses HR data. As this is a web-application, that a user must log onto
             to view their reward statement at UCL, a webservice here can work in a
             pull based manner.
             Total rewards application will call the service, to bring back employee
             data, when a user logs into the system.


             Thus the same webservice can be configured in a pull and push based
             manner based on the calling application. Advantage being, HR has a lesser
             interfaces to build and maintain.



                                                                                       39
Questions:


Q. [Maj]: What information can be updated back in ResourceLink from SiP?


Q. [Maj]: What are the point to point interfaces between SiP and other systems that
draw information from SiP.


Q. [Maj]: How many systems pull data from SiP.


Q. [Maj]: Is this data Real time/ Nightly updates/any other frequency?


Q5. How to design the webservice?
       PL/SQL
       Spring framework
       Pull/Push approach


Q6. How will external systems invoke this webservice.


Q7. Security considerations




                                                                                      40
9.6.   Other potential webservices
        I. UPI stands for UCL Person Identifier. This is a unique combination of
           alpha numeric characters for each user associated with UCL. It forms the
           basis of Identity of a person within UCL.
        II. Currently, UPI is exposed using views.
       III. Since many applications make use of UPI information, a webservice
            called getUPI would be a very useful step in the future.
       IV. A schema, uclperson.xsd, is already created. This schema contains
           information related to a person‟s identity and association within UCL, and
           could be used when developing webservices that deal with user related
           information such as UPI, username etc.
        V. This schema (and all its reference schemas) will be stored in wiki.




                                                                                  41
10.   Additional Considerations

  10.1. Load testing of webservices.
        Webservices are developed with an intention that it will be used by several
        clients. Load testing should be considered for these services.
        Just as one would have to include webservice analysis, design and
        development in project plans, load testing should also be considered
        depending on the scale of the webservice (potential reuse).
        E.g.: SOAP UI is a tool available that could be used for load testing the WS.
        This tool also integrates with development platforms like Eclipse.




  10.2. System integration
        Consider developing webservices when developing any interaction across
        independent systems. If there is work being planned to pull/push any
        information across two independent systems, teams should follow the points
        below as a checklist.
           1. Is developing this interaction as a webservice justified in terms of how
              many clients will be interested in this information?
           2. If it is a candidate to replace any point to point interfaces.
           3. A good start would be to speak to the webservices team which includes
              Simon Farrell from Information Services Division, Conrad Morgan and
              J. Anthony Rickaby from Management Systems.
           4. This team will help steering this new requirement through its design,
              implementation and deployment stages.
           5. A sign off could be needed during the design phase from the
              Webservices team.




                                                                                        42
APPENDIX A: CREATING AND MANIPULATING KEYSTORES
These commands allow you to generate a new Java Keytool keystore file and import
certificates.
Any root or intermediate certificates will need to be imported before importing the
primary certificate for your domain.
      Generate a Java keystore and key pair
       keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.jks


      Generate a certificate signing request (CSR) for an existing Java keystore
   keytool -certreq -alias mydomain -keystore keystore.jks -file mydomain.csr


      Import a root or intermediate CA certificate to an existing Java keystore
   keytool -import -trustcacerts -alias root -file Thawte.crt -keystore keystore.jks


      Import a signed primary certificate to an existing Java keystore
   keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore
   keystore.jks


      Generate a keystore and self-signed certificate
   keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass
   password -validity 360
   If you need to check the information within a certificate, or Java keystore, use these
   commands.


      Check a stand-alone certificate
   keytool -printcert -v -file mydomain.crt


      Check which certificates are in a Java keystore
   keytool -list -v -keystore keystore.jks


      Check a particular keystore entry using an alias
   keytool -list -v -keystore keystore.jks -alias mydomain


      Delete a certificate from a Java Keytool keystore
   keytool -delete -alias mydomain -keystore keystore.jks


      Change a Java keystore password
   keytool -storepasswd -new new_storepass -keystore keystore.jks




                                                                                       43
   Export a certificate from a keystore
keytool -export -alias mydomain -file mydomain.crt -keystore keystore.jks


   List Trusted CA Certs
keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts


   Import New CA into Trusted Certs
keytool -import -trustcacerts -file /path/to/ca/ca.pem -alias CA_ALIAS -keystore
$JAVA_HOME/jre/lib/security/cacerts




                                                                                   44

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:9/9/2011
language:English
pages:44