A MarkLogic XQuery module clientlib.xqy is available that provides the same functionality for XQuery applications as is provided for Java applications by ClientLib4J. You include the module in your namespace with the following declaration. Note, the value of the "at" directive must be the location of the clientlib.xqy file within your modules database and may vary from the value shown.
xquery version "1.0-ml"; import module namespace sso = "http://lds.org/code/shared/common/sso/clientlib" at "/auth/_app/module/clientlib.xqy";
Injected Headers Exposed
This module declares variables for each of the headers injected by the SSO environment. The value of these variables is the value passed in for the corresponding header or the empty sequence if the header is not found. The variables available and their corresponding header are:
|Name||Code||Where is it Defined?|
|Lds Account ID||$sso:LDSACCOUNTID||policy-ldsaccountid|
|Sign-In Query Parm||$sso:SIGNIN||policy-signin|
|Sign-out Query Parm||$sso:SIGNOUT||policy-signout|
Cookies, Sessions, and Tokens
As noted in SSO Environment Overview a REST api exists providing SSO services to a applications beyond header injection. The feature set of the REST serice is exposed by various methods of this module.
The getCookieName() as xs:string method returns the name of the cookie use in the SSO environment to convey the existence or lack of an SSO session. Applications my need to know this if they intend to perform server-side mashup of content from other SSO protected applications. For example, suppose another SSO protected application exposes some REST or SOAP service that your application leverages as part of handling server-side requests. If that service requires authentication then calls to it must include the SSO session cookie. In such a case the Mark Logic application will use a method such as xdmp:http-get to call and retrieve a resource from that service and will have to create the cookie header manually setting its value to that of the SSO cookie.
That brings us to getToken() as xs:string. This method returns the content of the SSO cookie or an empty sequence if the request does not have an SSO cookie. As noted, applications can use this in calling other SSO protected applications. But such could also be used to implement a database "based" cache using the SSO token as the key and scanning for expired sessions periodically to purge items in the cache. How does and application check for expired sessions?
Introducing the module's two session validity evaulation methods. isSessionValid() as xs:boolean answers true only if the current request has an SSO cookie and the value of that cookie represents a currently active session or false otherwise. areTokensValid($tokens as xs:string+) as map:map accepts a sequence of tokens and returns a map whose keys are the token strings and the values are of type xs:boolean indicating if that token represents a currently active session. Both methods leverage the REST api's areTokensValid endpoint and neither call impacts the current state of the session meaning that asking if a token is valid does not affect the session's timeout value.