[[security]]
== Security considerations 

=== Advertising Security

With so much focus on security in Testbed 12, it seems only natural that the
WIS should also discuss how to deal with this concept. Using the guidelines
outlined in the engineering document OGC 15-022, we can easily advertise the
security constraints in the WIS GetCapabilities document by using the
appropriate OWS Common Constraint element in the GetCapabilities operation
as outlined below: 

----
   <ows:Operation name="GetCapabilities">
      <ows:DCP>
         <ows:HTTP>
            <ows:Get xlink:href="http://ogc-testbed12.compusult.net/wes/wis?request=getCapabilities">
               <ows:Constraint name="urn:ogc:def:tb12:security:authentication">
                  <ows:ValuesReference ows:reference="http://tb12.opengis.net/security/authCodeList#HTTP_BASIC">
                 urn:ogc:def:tb12:ietf:2617:basic</ows:ValuesReference>
               </ows:Constraint>
            </ows:Get>
         </ows:HTTP>
      </ows:DCP>
      <ows:Parameter name="Format">
         <ows:AllowedValues>
            <ows:Value>application/xml</ows:Value>
            <ows:Value>application/x-bxml</ows:Value>
         </ows:AllowedValues>
      </ows:Parameter>
   </ows:Operation>
----

The general idea here is that service providers expose a public capabilities
document. Then, within that document they advertise the methods that are
available for users and/or clients to authenticate against. Any entity that
authenticates successfully would then be given access to other services that
would not be accessible otherwise. 

In the sample above, the 'GetCapabilities' operation is advertising that users
and/or clients can authenticate using 'Basic Authentication' but other methods
are also available including: client certificate and user name token. A
complete list of the available methods can be found here :http://tb12.opengis.net/security/authCodeList

=== Storing Security information in an ebRIM CSW Catalogue.

When security information is advertised in a service's capabilities document
it is very important that this information is captured properly so that it can
be accessed and/or displayed later. 

Typically, when a service capabilities document is published in a CSW catalogue
it creates an ebRIM Service object that is then associated with various
applicable objects within the ebRIM data model. 

Because a service's associated security constraints are tied to its operations,
it is recommended that a new ebRIM Association object with an association type
called urn:ogc:def:ebRIM-AssociationType:OGC:HasConstraint be used to associate
each ebRIM service binding to its associated constraints. 

Each constraint object should be a new ExtrinsicObject with an object type =
urn:ogc:def:ebRIM-ObjectType:OGC:Constraint that has an associated Slot called
AllowedValues which contains the list of values permitted for the constraint.
The figure, _<<ebrim_service_sec_assoc,ebRIM Service Security Association>>_
shows what an ebRIM catalogue might look like after a WIS capabilities
document has been successfully harvested.

[[ebrim_service_sec_assoc]]
.The ebRIM Service Security Association
image::includes/images/ServiceSecurityAssociation.png["ebrim_service_sec_assoc",scaledwidth="70%",align="center"]

=== Public and Private WIS Service objects

During a typical CSW publishing flow for a Web Integration Service (WIS) it is
recommended that the CSW catalogue maintain which of the services listed in the
GetCapabilities document have Public access and which ones have Private access.
If you recall, the Private services are those returned by the service after the
user and/or client has been authenticated.

It is recommended that this be accomplished by classifying each service properly
using the new Access Types classification scheme.  The classification scheme
Access Types is defined as: 

[[class_scheme_access_types]]
.Classification Scheme of Access Types
image::includes/images/ClassificationScheme_AccessTypes.png["class_scheme_access_types",scaledwidth="70%",align="center"]