The SOSI Library Programmers Guide 2.1

Transcription

1 The SOSI Library Programmers Guide 2.1 1/52

2 1 Introduction Library concepts Set-up Pre-requisites Downloading the library A demo installation Certificates and cryptosystems How-To (Tutorials) Setting up properties Sequence Diagrams Use case 1: How to authenticate an ID-card Create SOSIFactory Create a Request Create an ID-card Assign the ID-card to the request Build the XML representation Signing the ID-card Send request to Security Token Service Extract ID-card for use Use case 2: How to call a Service Provider Add the ID-card Extract the service reply from the Reply object Use case 3: How to issue an ID-card (STS functionality) How to create the Request from XML How to verify the information in the ID-card How to sign the ID-card How to send the reply Use case 4: How to reply to a service request Use case 5: Request an Identity token from a STS Create IDWSHFactory Create a request Retrieve the Identity token Use case 6: Call a service provider using an Identity token Use case 7: Issue an Identity token Retrieve the Identity token request Creating an Identity token Creating an Identity token response Use case 8: Retrieve and use an Identity token Use case 9: Exchange an OIOSAML assertion to an IDCard at a STS Create an OIOSAMLFactory Create an OIOSAMLAssertionToIDCardRequest Parse an OIOSAMLAssertionToIDCardResponse Use case 10: Issue an IDCard based on a OIOSAML assertion Parse an OIOSAMLAssertionToIDCardRequest Create an OIOSAMLAssertionToIDCardResponse /52

4 1 Introduction This document is a guide for users of the SOSI library, also known as Seal.Java. The document contains information about how to install and configure the library, and documents details on how to use the library as a service consumer or a service provider. This document is not a design document and hence will not go into detail about e.g. how XML signature is used in the SOSI envelope format etc. Neither will it cover all the basic concepts of Webservice Single-Sign-On, federations etc. If you need information about the concepts etc. please refer to Den Gode Webservice documentation. The SOSI library is presently implemented as a Java library and the reader must therefore be an intermediate Java programmer. The reader must also have basic knowledge about public key cryptography (signing) and XML. The most recent version of this document can be found online here: 4/52

5 2 Library concepts The primary goal for the SOSI library is to encapsulate most of the complex logic in the SOSI concept behind a very simple API. It has been our goal to construct a single point of entry for all programmers (a factory) from which it is possible to acquire simple model objects (POJO s 1 ) that are representing the core concepts in the SOSI scheme, e.g. a Message or an ID Card. Once the programmer has constructed these model objects, it is possible to serialize them into XML and vice versa. The de-serialization (from XML to model objects) is also done through the factory. Error! Reference source not found. below shows a very simple flow, where a service consumer (e.g. a medication system) is creating a Request message, setting it up, serializing it into XML and sends it to a Service consumer. Service Consumer SOSIFactory Service Provider 1. new SOSIFactory(...) 2. createnewrequest(...) Request 3. new Request 4. setidcard(...) 5. todomdocument(...) XmlUtil 6. return DOM document 7. node2string(dom) 8. return XML String 9. sendrequestwebservice(xml) Figure 1 - a simple service consumer usage. 1 Plain Old Java Object 5/52

6 As of version 2.1 Seal.Java now includes the IDWSHFactory. Version 2.1 marks the beginning of IDWSH support. Further versions of Seal.Java will greatly expand the support and workflow using IDWSH. Seal.Java 2.1 only supports IDWSH identity tokens. The flow for constructing and using Identity tokens is shown in Figure 2. Figure 2 - IDWSH Identity token workflow. As can be seen from the two examples, the programmer does not at any time produce (or code) any XML, the programmer does not make digests or digital signatures. This kind of complex logic is encapsulated behind elements from the library. In Seal the OIOSAMLFactory was introduced which provides functionality to create, parse, sign and validate OIOWS-Trust messages that are used when exchanging OIOSAML assertions that are issued by and IdP to SOSI IDCards. The core POJO s make up a simple object hierarchy as shown below in Figure 3: 6/52

7 Message IDCard Request Reply SecurityTokenRequest SecurityTokenResponse SystemIDCard SystemInfo 1 1 SOSIFactory UserIDCard UserInfo 1 1 Figure 3 The POJO class relationships The class diagram is almost self-explanatory. To the left you find the main abstraction of messages (Request, Reply etc). SecurityTokenRequest and SecurityTokenResponse are messages used for establishing federation credentials. Messages can have an ID-card attached. This ID-card can either be a system ID-card or a user ID-card, depending on the type of service. If the service requires information about a specific user in order to execute, the ID-card needs to be a UserIDCard. An example of such a service could be requesting information about medication for patient from the Danish Medicines Agency. In this case the service provider needs proof of the user s identity. In other cases, e.g. when delivering data to the Danish Medicines Agency in nightly batches, it is only necessary to know the identity of the system. In this case a SystemIDCard is sufficient. The entry point for programmers is always the SOSIFactory, the IDWSHFactory or the OIOSAMLFactory. From here it is possible to create new request objects, reply objects, ID-cards, IdentityTokens, etc. as well as to de-serialize XML into copies of objects from the sender side. Both factories have a CredentialVault associated. The CredentialVault is a simple encapsulation of PKCS 2 elements: a (possibly empty) set of trusted X.509 certificates and zero or one public-private key-pair. The CredentialVault is passed to the SOSIFactory at construction time. 2 Public Key Crypto System 7/52

8 The concrete realization of the vault may vary with the environment in which the library is used. In a simple environment, the realization could be a file based CredentialVault that reads a PKCS#12 file and trusted X.509 certificates from the disk 3, or a realization based on a database/cache in a complex J2EE environment. If you have no need of strong credentials (i.e. on authentications level 1), you can construct SOSIFactory with EmptyCredentialVault, which is an empty implementation of the CredentialVault interface. The class relationships are shown below in Figure 4. Figure 4 - CredentialVault dependencies The configuration may further supply the notion of a Federation within which the application using the library should operate. The federation is defined in terms of the certification authority issuing the certificates used within the federation, and the identity of the STS. If (and only if) a federation is defined, the library may automatically perform revocation checks when verifying digital signatures on retrieved ID-cards. The library will also be robust against renewal of the STS certificate. 3 An example of such a file based credential vault can be found in the library 8/52

9 The Federation is the preferred mechanism for establishing trust within SOSI, and users are strongly encouraged to make use of the built-in federations of the SOSI library. Once the SOSIFactory has been created, it is straightforward to get started. Consider the following code snippet that contains code for constructing a request to send to a service provider: Properties properties = ; SOSITestFederation testfederation = new SOSITestFederation(properties); CredentialVault credentialvault = <construct or resolve credentialvault here>; SOSIFactory factory = new SOSIFactory(testFederation, credentialvault, properties); Request request = factory.createrequest( false, // don t require non-repudiation receipt null // Optional flow-id (not used here) ); IDCard idcard = <resolve ID-card here>; request.setidcard(idcard); Element body = <build body DOM element here>; request.setbody(body); Document domdocument = request.serialize2domdocument(); String xml = XmlUtil.node2String(domDocument, false, true); <Send xml to Service provider here> The real work for the developer is in the blue sections above, i.e.: Specifying properties for SOSI, see later for reference on SOSI properties Constructing/resolving the credential vault instance Constructing/resolving the ID card instance Building the body XML Sending the xml to the receiver. In other words; the workload for the developer is greatly reduced compared to a situation where this library was not applicable. On the other side (at the service provider) the library is used as follows: 9/52

11 3 Set-up This chapter describes how to install and set up the SOSI library, i.e. how to download, unpack and configure the library, how to handle dependencies etc. 3.1 Pre-requisites The library has been tested on Oracle JDK-1.5.0, Oracle SDK and Oracle SDK There are the following run-time dependencies: JDK Bcmail-jdk Bcprov-jdk Commons-codec 1.5 Commons-httpclient 3.1 Commons-logging Xalan Xml security some logging library compatible with commons-logging e.g. log4j Some of the crypto operations (e.g OCES signature verification) need access to crypto algorithms with unbounded strength. The JDK s are shipped with policy files that support strong but not unbounded encryption strength. However Oracle does distribute policy files that allow unbounded encryption strength. You can download or extract US_export_policy.jar and local_policy.jar from: Oracle 1.5: Oracle 1.6: Oracle 1.7: The files must replace the existing files in $JRE_HOME 4 /lib/security. 3.2 Downloading the library The library is hosted by the component library facility at Ministry of Science, Technology and Innovation in Denmark. The download area can be found here: In the download area you can download a ZIP file containing binaries, test-binaries, sources, documentation, dependency libraries etc. Seal.Java also contains a number of demos. 4 Please note that JRE is placed in $JAVA_HOME/jre on Windows platforms. 11/52

12 The demos are useful for development and should not be distributed to production systems. Installing them requires some extra steps in comparison to installing the SEAL component. The rest of this chapter will concentrate on how to install the SEAL library. Please refer to a later chapter for instructions on how to install the demos. 3.3 A demo installation Now that the JDK is properly configured you should try following the steps below to make a demo installation. Please consult the SOSI knowledge base (Q/A) if any problems should occur (http://www.sosi.dk/twiki/bin/view/projectmanagement/sosiknowledgebase): 1. Open the ZIP file and extract to somewhere appropriate on your disk 2. Start a shell (command prompt) and navigate to the bin directory of the installation (sosi/bin) 3. Run the runtest.sh (on unix/linux) or runtests.cmd (on windows). 4. If you see something like this, your JDK is configured correctly and the library is ready for usage: Figure 5 - Expected result from running "runtests.cmd" in a windows shell. This means that all unittests in the seal module has been executed without any problems. 3.4 Certificates and cryptosystems The SOSI library does not require a specific JCE crypto provider to run. There are, however, some requirements to the crypto providers used: The crypto provider must provide the RSA-SHA1 algorithm. If system credentials are stored in #PKCS12 files the crypto provider must be able to read the #PKCS12 format. 12/52

13 If the built in mechanism for certificate revocation check is used, an external crypto provider supporting X.509 may be needed. If you do not have a crypto provider that honors these requirements, one of the most acknowledged free providers is the Bouncy Castle crypto provider (http://www.bouncycastle.org/). Note: Unfortunately the Seal Tool, a special part of the library used for bootstrapping and renewing credential vaults, uses crypto provider features not standardized by JCE. This results in crypto provider classes being called directly. To decouple this dependency and to enable you to use your favorite crypto provider, the library comes with the CertificateRequestHandler, interface and a default BouncyCastle realization. Your own realization can be configured via sosi properties. As mentioned above the specific way of handling primary keys is not specified in the library. Either you will have to make your own realization of the CredentialVault interface or, if your environment allows it, you can use the FileBasedCredentialVault, RenewableFileBasedCredentialVault or the ClasspathCredentialVault, all of which are supplied with the library. FileBasedCredentialVault reads and writes PKCS entries to the filesystem. RenewableFileBasedCredentialVault is an extension of FileBasedCredentialVault allowing the user to renew VOCES certificates using a webservice, while ClasspathCredentialVault looks for a specific keystore in the classpath. The SOSI library comes with a tool for creating this keystore. Please refer to section 7 for instructions. If you choose to implement your own credential vault you should take a look at the FileBasedCredentialVault, RenewableFileBasedCredentialVault, ClasspathCredentialVault, and GenericCredentialVault for inspiration. A Credential vault can be realized in various ways: 1. Letting a database store the trusted certificates and system credentials. 2. Including the trusted certificates and system credentials in the distribution of the application (EAR, WAR, JAR file). 3. Loading the credentials and certificates once at startup (from a secret file/directory/cd) and storing the credentials and certificates in a cache. 4. If running on an application server the credential vault could integrate to the trust store and credential store on the application server. 5. A hard coded class containing the trusted certificates (STS certificate) and system credentials (primary key for this system). Please note that the use of CredentialVault for storing federation certificates has been deprecated in favor of the Federation mechanism. It is highly recommended to let a CredentialVault store only private certificates and keys when used with federations. As mentioned before the SOSI library also includes the EmptyCredentialVault, which is used when no credential vault is needed. EmptyCredentialVault throws 13/52

14 CredentialVaultException if its methods get called, because this means that you are trying to handle a security level above level 1. 14/52

15 4 How-To (Tutorials) This chapter describes how to utilize the SOSI-component for communicating using the SOSI protocol. The component supports use cases for the Service Consumer, the STS and the Service Provider, and these are described individually below: Service Consumer use cases 1. Request an ID-card authentication from a STS 2. Call a Service Provider STS use cases 3. Issue an ID-card Service Provider use cases 4. Reply to a service request Service Consumer use cases (Identity token) 5. Request an Identity token from a STS 6. Call a service provider using an Identity Token STS use cases (Identity token) 7. Issue an Identity token Service Provider use cases (Identity token) 8. Retrieve and verify an Identity token. Service Consumer use cases (OIOSAML assertion to IDCard) 9. Exchange an OIOSAML assertion to an IDCard at a STS STS use cases (OIOSAML assertion to IDCard) 10. Issue an IDCard based on a OIOSAML assertion Service Consumer use cases (IDCard to encrypted OIOSAML assertion) 11. Exchange an IDCard to an encrypted OIOSAML assertion at a STS STS use cases (IDCard to encrypted OIOSAML assertion) 12. Issue an encrypted OIOSAML assertion based on an IDCard 15/52

16 4.1 Setting up properties The library can be customized with a few properties that are passed to the constructor of the SOSIFactory. Currently the supported properties are: sosi:validate = { true, false } Indicates whether or not the DOM parser should validate XMLSchemas for SOSI envelopes. The default value is true (i.e. if the property is not specified, the library will validate) sosi:usedbfcache = { true, false } Indicates whether or not the DOM parser factory (DocumentBuilderFactory) should be cached or not. The default value is true (i.e. if the property is not specified, the factory will get cached). sosi:issuer = some String The name of the system that is using the library. The value will be inserted into ID-cards when issuing new ID-cards model objects. The default value is TheSOSILibrary. sosi:rootschema = some String The root schema file to validate against. The default value is soap.xsd, which is the rootschema for validating the soapheaders. If you want your body validated by the framework you need to define your elements in a new schema and import soap.xsd. The framework load schema files as resources from the classpath. sosi:federation.audithandler = class name User provided audit handler to be called, when an audit event arises during a certificate revocation check. Please refer to later section on customizations The SOSI libray supplies two built-in audithandlers dk.sosi.seal.pki.noauditeventhandler which sinks all events, which is the default implementation dk.sosi.seal.pki.commonsloggingauditeventhandler which logs using apache commons logging. sosi:cryptoprovider.x509 = provider name This enables you to change the provider used for handling x509 certificated. The default value is BC (Bouncy Castle). sosi:cryptoprovider.pkcs12 = provider name This enables you to change the provider used for handling PKCS12. Only used if credentials are stored in pkcs#12 format. The default value is BC (Bouncy Castle). sosi:cryptoprovider.rsa = provider name This enables you to change the provider used for handling RSA. The default value is BC (Bouncy Castle). 16/52

20 Service execution is performed in the same manner regardless of the authentication level on the IDcard. Figure 8 illustrates a service call with all participants, and hence covers use cases 2 and 4: EHR Client EHR Server Service Provider 1. invoke business service 2. fetch ID-card from cache 3. create Request from factory 4. Add ID-card to request 5. Add service input to Request 8. invoke web service 9. Create SOSI Factory 10. Create Request from XML 11. Get ID-card and authorize user 12. Execute web service 14. Return Reply as XML 13. Create Reply 16. Return response 15. Execute busines logic Figure 8 - Sequence diagram illustrating use cases 2 and Use case 1: How to authenticate an ID-card The steps needed in creating a request for authenticating an ID-card are listed below: 1. Create SOSIFactory 2. Create a Request 3. Create an ID-card 4. Build the XML representation 5. Sign the ID-card 6. Send request to the STS 7. Extract ID-card for use Create SOSIFactory All model objects in SOSI are created through the SOSIFactory, which must be initialized before creating model objects: 20/52

21 Properties properties = new Properties(); properties.setproperty("sosi:issuer", "XXXX"); // possibly specify other properties here... Federation federation = new SOSIFederation(properties); CredentialVault cv = new ClasspathCredentialVault(KEYSTORE_PASSWORD); SOSIFactory factory = new SOSIFactory(federation, credentialvault, properties); Please note that the actual type of CredentialVault may vary depending on the type of environment you need to run the application in. The ClassPathCredentialVault may fit perfectly for some situations. In other situations you may have to develop a new CredentialVault realization that retrieves keys and certificates from some other persistent store (e.g. a database). If so you should consider subclassing GenericCredentialVault. In this example we instantiate a ClasspathCredentialVault. This type of credential vault is a read-only credential vault that reads keys and certificates from a special keystore that must be found on the class path. Use the SEAL tool to generate a JAR file containing this special keystore (see chapter 7). The SOSI library has 2 built-in Federations Properties properties = new Properties(); properties.setproperty("sosi:issuer", "XXXX"); Federation testfederation = new SOSITestFederation(properties); // or SOSIFederation federation = new SOSIFederation(properties); Create a Request Use the SOSIFactory to create the request. The createnewrequest method takes two parameters: The request for nonrepudiation, and the flowid, which identifies the communication sequence. The flow ID is optional and hence may be null. If the flow ID is null, the corresponding element in the XML is not created. // Create a simple request object Request request = factory.createnewrequest(false,null)); Create an ID-card Again use the SOSIFactory for creating the ID-cards. SOSI supports both SystemIDCards and UserIDCards. The difference between the two types of ID-cards is that SystemIDCards only contain information identifying the client system, while UserIDCards also contain information for identifying the client user. According to the DGWS specification ID-cards must expire after at most 24 hours. However, to prevent problems from server clocks not being synchronized, the ID-cards issued by the SOSI library are displaced 5 minutes so that the start time of the ID-Card is now minus 5 minutes and the expiration time is now plus 23:55. 21/52

22 A SystemIDCard is created by providing information on the name of the system, a CareProvider, the authentication level and the certificate used to sign the ID-card: // Create a system ID-card IDCard card = factory.createnewsystemidcard( "SOSITEST", new CareProvider(SubjectIdentifierTypeValues.SKS_CODE, "1234", "sosi"), AuthenticationLevel.VOCES_TRUSTED_SYSTEM, factory.getcredentialvault().getsystemcredentialpair().getcertificate() ); To create a UserIDCard the above mentioned information must be complemented by user data, authorization code and whether the ID-card should be signed by a VOCES or a MOCES certificate: // create a new User ID-card IDCard card = factory.createnewuseridcard( systemname, cpr, givenname, surname, , surgeon, UserRole.DOCTOR, new CareProvider(CareProvider.CAREPROVIDER_TYPE_CVR, orgcvr, orgname), authorizationcode, AuthenticationLevel.MOCES_TRUSTED_USER, factory.getcredentialvault().getsystemcredentialpair().getcertificate()) ) ); There are several embedded objects in user ID cards that defines the context this user is acting in: SystemName the name of the system that this user was using when this ID-card was issued. UserRole indicates which role the user has when using this ID-card. Presently only Doctor or Nurse are valid values. The set of valid user roles will most probably be extended in future releases. CareProvider an object representing the organizational unit that the user is acting for. The AuthenticationLevel object defines the level of trust another system can have to this ID-card. Presently three of the five levels in Den Gode Webservice are supported: NO_AUTHENTICATION the user does not need to present credentials (DGWS level 1). VOCES_TRUSTED_SYSTEM the user is implicitly trusted through the system that the user is using (DGWS level 3). MOCES_TRUSTED_USER the user will present a digital signature based on a employee certificate (DGWS level 4). 22/52

Enabling SSL and Client Certificates on the SAP J2EE Engine Angel Dichev RIG, SAP Labs SAP AG 1 Learning Objectives As a result of this session, you will be able to: Understand the different SAP J2EE Engine

www.novell.com/documentation Policy Guide Access Manager 3.1 SP5 January 2013 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation,

IBM i Security Digital Certificate Manager 7.1 IBM i Security Digital Certificate Manager 7.1 Note Before using this information and the product it supports, be sure to read the information in Notices,

E-mail Listeners 6 E-mail Formats You use the E-mail Listeners application to receive and process Service Requests and other types of tickets through e-mail in the form of e-mail messages. Using E- mail

CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is

Version 2.4.2 This edition of SDK Code Examples refers to version 2.4.2 of. This document created or updated on February 27, 2014. Please send your comments and suggestions to: Black Duck Software, Incorporated

System i Security Digital Certificate Manager Version 5 Release 4 System i Security Digital Certificate Manager Version 5 Release 4 Note Before using this information and the product it supports, be sure

Fairsail REST API: Guide for Developers Version 1.02 FS-API-REST-PG-201509--R001.02 Fairsail 2015. All rights reserved. This document contains information proprietary to Fairsail and may not be reproduced,

QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,

Setup Guide Access Manager 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE

Enabling SSL and Client Certificates on the SAP J2EE Engine Angel Dichev RIG, SAP Labs Learning Objectives As a result of this session, you will be able to: Understand the different SAP J2EE Engine SSL

How SSO Works in WhosOnLocation About Single Sign-on By default, your administrators and users are authenticated and logged in using WhosOnLocation s user authentication. You can however bypass this and

IBM Campaign Version-independent Integration with IBM Engage Version 1 Release 3 April 8, 2016 Integration Guide IBM Note Before using this information and the product it supports, read the information

Setup Guide Access Manager Appliance 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS

INTEGRATE SALESFORCE.COM SINGLE SIGN-ON WITH THIRD-PARTY SINGLE SIGN-ON USING SENTRY A GUIDE TO SUCCESSFUL USE CASE Legal Marks No portion of this document may be reproduced or copied in any form, or by

CHAPTER 1 Note The information in this chapter applies to both the ACE module and the ACE appliance unless otherwise noted. The features in this chapter apply to IPv4 and IPv6 unless otherwise noted. Secure

KMx Enterprise: Integration Overview for Member Account Synchronization and Single Signon KMx Enterprise includes two api s for integrating user accounts with an external directory of employee or other

IBM Campaign and IBM Silverpop Engage Version 1 Release 2 August 31, 2015 Integration Guide IBM Note Before using this information and the product it supports, read the information in Notices on page 93.

LabVIEW Internet Toolkit User Guide Version 6.0 Contents The LabVIEW Internet Toolkit provides you with the ability to incorporate Internet capabilities into VIs. You can use LabVIEW to work with XML documents,

IBM SPSS Collaboration and Deployment Services Version 6 Release 0 Single Sign-On Services Developer's Guide Note Before using this information and the product it supports, read the information in Notices

OIOIDWS for Healthcare Token Profile for Authentication Tokens Common Web Service Profile for Healthcare in the Danish Public Sector, version 2.0 Content Document History...3 Introduction...4 Notation...

CHAPTER 4 This chapter describes the steps required to configure a CSS as a virtual SSL server for SSL termination. It contains the following major sections: Overview of SSL Termination Creating an SSL

NetIQ Identity Manager Setup Guide July 2015 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE

ADSS Server is a multi-function server providing digital signature creation and signature verification services, as well as supporting other infrastructure services including Time Stamp Authority (TSA)

vcloud Air Platform Programmer's Guide vcloud Air OnDemand 5.7 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition.

Xerox DocuShare Security Features Security White Paper Xerox DocuShare Security Features Businesses are increasingly concerned with protecting the security of their networks. Any application added to a

CA SOA Security Manager Implementation Guide r12.1 Second Edition This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational

Load testing with WAPT: Quick Start Guide This document describes step by step how to create a simple typical test for a web application, execute it and interpret the results. A brief insight is provided

www.novell.com/documentation Jobs Guide Identity Manager 4.0.1 February 10, 2012 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation,

Chapter 4 Virtual Private Networking This chapter describes how to use the virtual private networking (VPN) features of the FVL328 Firewall. VPN tunnels provide secure, encrypted communications between

Online signature API Version 0.20, 2015-04-08 Terms used in this document Onnistuu.fi, the website https://www.onnistuu.fi/ Client, online page or other system using the API provided by Onnistuu.fi. End

Unleash the Power of e-learning Revision 1.8 June 2014 Edition 2002-2014 ICS Learning Group 1 Disclaimer ICS Learning Group makes no representations or warranties with respect to the contents or use of