$Web End SSLSes: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (1 revision)
(Automatically generated page update)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:$Web_End_SSLSes}}
{{DISPLAYTITLE:$Web_End_SSLSes}}
<span class="pageSubtitle"><section begin="desc" />Terminate an SSL session<section end="desc" /></span>
<span class="pageSubtitle">Terminate an SSL session</span>


$Web_End_SSLSes terminates an SSL session.
<var>$Web_End_SSLSes</var> terminates an SSL session.


$Web_End_SSLSes takes no arguments and returns a [[#Status codes|status code]]. It is a [[Calling_Sirius_Mods_$functions|callable]] $function.
<var>$Web_End_SSLSes</var> takes no arguments and returns a [[#Status codes|status code]]. It is a [[Calling_Sirius_Mods_$functions|callable]] $function.


==Syntax==
==Syntax==
<p class="syntax"><section begin="syntax" />%rc = $Web_End_SSLSes
<p class="syntax"><span class="term">%rc</span> = $Web_End_SSLSes
<section end="syntax" /></p>
</p>


===Status codes===
===Status codes===
Line 24: Line 24:
==Usage notes==
==Usage notes==
<ul>
<ul>
<li>The most likely reason to use $Web_End_SSLSes is to force a <var class="product">[[Janus Web Server]]</var> client, that is, a browser, to re-send the previously sent client certificate or to send a new one. This is especially useful if user login sessions are being maintained via SSLSES and the userid had been derived directly or indirectly from the client certificate. It would also be useful in cases where client certificate information is used to control access to certain resources.  
<li>The most likely reason to use <var>$Web_End_SSLSes</var> is to force a <var class="product">[[Janus Web Server]]</var> client, that is, a browser, to re-send the previously sent client certificate or to send a new one. This is especially useful if user login sessions are being maintained via SSLSES and the userid had been derived directly or indirectly from the client certificate. It would also be useful in cases where client certificate information is used to control access to certain resources.  
<p>
<p>
Forcing or allowing a browser to send a new client certificate lets the browser's end user change "roles" by sending a certificate associated with the new role. For example, a single end user might be allowed to view corporate accounting information and personnel information for her own department. Access to these two areas might be authorized by two different client certificates. So if the user attempted to access the personnel information while the accounting certificate was "active," it might be useful for the personnel application to do a $WEB_END_SSLSES, then redirect the browser back to the originally requested URL to allow the user to present a different client certificate. </p>
Forcing or allowing a browser to send a new client certificate lets the browser's end user change "roles" by sending a certificate associated with the new role. For example, a single end user might be allowed to view corporate accounting information and personnel information for her own department. Access to these two areas might be authorized by two different client certificates. So if the user attempted to access the personnel information while the accounting certificate was "active," it might be useful for the personnel application to do a <var>$Web_End_SSLSes</var>, then redirect the browser back to the originally requested URL to allow the user to present a different client certificate. </p>
<p>
<p>
$Web_End_SSLSes might also be useful to force an end user to resend a client certificate when a NEWSESCMD is run because of a timed out session. While this situation might be difficult to detect, it should be possible with the use of an indicator cookie that is set after a successful $SIR_LOGIN and cleared after a $WEB_ENDSSLSES. </p>
<var>$Web_End_SSLSes</var> might also be useful to force an end user to resend a client certificate when a NEWSESCMD is run because of a timed out session. While this situation might be difficult to detect, it should be possible with the use of an indicator cookie that is set after a successful $SIR_LOGIN and cleared after a <var>$Web_End_SSLSes</var>. </p>


<li>$Web_End_SSLSes can be used in a "logout" page that terminates the use of a client certificate on a public or semi-public workstation, though it may be questionable to depend on end users remembering to go to the logout page to terminate a session. It is probably better to train end users to completely exit the browser when on a public or semi-public workstation, which should end all SSL sessions with all servers.
<li>$Web_End_SSLSes can be used in a "logout" page that terminates the use of a client certificate on a public or semi-public workstation, though it may be questionable to depend on end users remembering to go to the logout page to terminate a session. It is probably better to train end users to completely exit the browser when on a public or semi-public workstation, which should end all SSL sessions with all servers.

Latest revision as of 14:55, 9 April 2013

Terminate an SSL session

$Web_End_SSLSes terminates an SSL session.

$Web_End_SSLSes takes no arguments and returns a status code. It is a callable $function.

Syntax

%rc = $Web_End_SSLSes

Status codes

Code Meaning
-1 Not a Web Server thread.
0 Session terminated.
1 A Web Server thread but not an SSL connection.

Usage notes

  • The most likely reason to use $Web_End_SSLSes is to force a Janus Web Server client, that is, a browser, to re-send the previously sent client certificate or to send a new one. This is especially useful if user login sessions are being maintained via SSLSES and the userid had been derived directly or indirectly from the client certificate. It would also be useful in cases where client certificate information is used to control access to certain resources.

    Forcing or allowing a browser to send a new client certificate lets the browser's end user change "roles" by sending a certificate associated with the new role. For example, a single end user might be allowed to view corporate accounting information and personnel information for her own department. Access to these two areas might be authorized by two different client certificates. So if the user attempted to access the personnel information while the accounting certificate was "active," it might be useful for the personnel application to do a $Web_End_SSLSes, then redirect the browser back to the originally requested URL to allow the user to present a different client certificate.

    $Web_End_SSLSes might also be useful to force an end user to resend a client certificate when a NEWSESCMD is run because of a timed out session. While this situation might be difficult to detect, it should be possible with the use of an indicator cookie that is set after a successful $SIR_LOGIN and cleared after a $Web_End_SSLSes.

  • $Web_End_SSLSes can be used in a "logout" page that terminates the use of a client certificate on a public or semi-public workstation, though it may be questionable to depend on end users remembering to go to the logout page to terminate a session. It is probably better to train end users to completely exit the browser when on a public or semi-public workstation, which should end all SSL sessions with all servers.