ZXID.org Identity Management toolkit implements standalone SAML 2.0 and Liberty ID-WSF 2.0 stacks. The logging module described in this document allows various degrees of digital signing and encryption to be configured to ensure tamperproofness and confidentiality of the logs. Of course such operations come at a cost.
All ZXID logging is filesystem based and consists mainly of text files to which lines are appended. This document describes the filesystem layout for other purposes as well (to keep it all in one place). The logging system has also some tactical uses, such as detecting duplicate messages and assertions - within validity period, they are detected by checking if corrseponding blob log already exists.
mod_auth_saml Apache module documentation: SSO without programming.
zxid_simple() Easy API for SAML
ZXID Raw API: Program like the pros (and fix your own problems). See also Function Reference
ZXID ID-WSF API: Make Identity Web Services Calls using ID-WSF
ZXID Compilation and Installation: Compile and install from source or package. See also INSTALL.zxid for quick overview.
ZXID Configuration Reference: Nitty gritty on all options.
ZXID Circle of Trust Reference: How to set up the Circle of Trust, i.e. the partners your web site works with.
ZXID Logging Reference: ZXID digitally signed logging facility
javazxid: Using ZXID from Java
Net::SAML: Using ZXID from Perl
php_zxid: Using ZXID from PHP
zxididp: Using ZXID IdP and Discovery
README.smime: Crypto and Cert Tutorial
FAQ: Frequently Asked Questions
README.zxid: ZXID project overview
The logging API is further described in the full ZXID API Reference, which see. In summary, the logging functions are
int zxlog_dup_check(struct zxid_conf* cf, struct zx_str* path, char* logkey); int zxlog_blob(struct zxid_conf* cf, int logflag, struct zx_str* path, struct zx_str* blob, char* lk); int zxlog(struct zxid_conf* cf, struct timeval* ourts, struct timeval* srcts, char* ipport, struct zx_str* entid, struct zx_str* msgid, struct zx_str* a7nid, struct zx_str* nid, char* sigval, char* res, char* op, char* arg, char* fmt, ...);
of which zxlog() is by far the most used. A typical invocantion could be
// 1 2 3 4 5 6 7 8 9 10 11 12 13 14 zxlog(cf, 0, 0, 0, 0, 0, 0, 0, "N", "B", "ERR", cgi->eid, "Desc %s", foo);
Where
ZXID configuration object, used for configuration options and memory allocation
Timestamp as observed by localhost. Typically the wall clock time. See gettimeofday(3)
Timestamp claimed by the message to which the log entry pertains
IP address and port number from which the message appears to have originated
Entity ID to which the message pertains, usually the issuer. Null ok.
Message ID, can be used for correlation to establish audit trail continuity from request to response. Null ok.
Assertion ID, if message contained assertion (outermost and first assertion if there are multiple relevant assertions). Null ok.
Name ID pertaining to the message
Signature validation letters
Result letters
Operation code for the message
Operation specific argument
Free format message conveying additional information
N.B. zxidconf.h contains a wealth of logging related config options, see ZXID Configuration Reference
Tip: Your web server also has logging options. You may want to correlate the web server logs with zxid audit logs.
In serious use of SSO it is fundamental that the relying party, the SP, WSC, or WSP, archives the digitally signed evidence that justifies its actions. Generally this means that at least the SSO or credential assertions have to be archived. Quite often, especially in the WSC world, the entire SOAP response (which may be partially signed) needs to be preserved as a proof of an authorized action or attested attributes.
To lesser extent, it is also important that the issuing party, the IdP (or sometimes the DS, PS, WSC, or WSP), keeps records so that it can confirm or refute the claims of the relying party -- in the minimum it should be able to refute any obviously false claim and it should be able to detect breaches of its own security arrangements, e.g. situations where somebody is signing messages in its name although internal audit trail demonstrates this to be impossible. The IdP audit trail consists of preserving any (signed) request made by anyone as well as preserving every (signed) response it makes.
Generally every assertion, request, and response will have its unique
ID that can be used as the primary key, or filename, for storing it in
a database. Unfortunately these namespaces
are not disjoint
(it is not very well specified in any of the standards how they
interact or how wide their uniqueness properties are). The only safe assumption is the pessimistic one: each
type of object observes a unique namespace only towards its issuer and
type and hence we need to map such namespaces to subdirectories.
Please consider following layout of the log directory:
/var/zxid/
|
+-- zxid.conf Main configuration file
+-- pem/ Our certificates
+-- cot/ Metadata of CoT partners (metadata cache)
+-- ses/ Sessions (see refinement in Sesstion Storage section)
`-- log/ Log files, pid files, and the like
|
+-- issue/
| |
| +-- SHA1NAME/ Evidence issued to entity is kept in directory named after entity ID
| | |
| | +-- a7n/ Assertions issued to the given 3rd party, named by AssertionID
| | +-- msg/ Messages of any type issued to the given 3rd party, named by MessageID
| | `-- wir/ Wire messages, such as redirects, and posts (e.g. POST SimpleSign)
| ...
| `-- SHA1NAME2/ Evidence issued to another entity ID
|
+-- rely/
| |
| +-- SHA1NAME/ Evidence from entity is kept in directory named after entity ID
| | |
| | +-- a7n/ Assertions from 3rd parties, named by AssertionID
| | +-- msg/ Messages of any type from 3rd parties, named by MessageID or sha1
| | `-- wir/ Wire messages, such as redirects, and posts (e.g. POST SimpleSign)
| ...
| `-- SHA1NAME2/ Evidence from another entity ID
|
+-- tmp/ Subdirectory used for atomic operations ā la Maildir
+-- act Global activity log
+-- err Global error log
`-- debug Global debugging log
The log file is line oriented, one record per line irrespective of line length, and plain text: binary data is generally omitted or represented as (safe) base64. Fields are separated by exactly one space character (0x20), except for the last free format field. Records are separated by exactly one new line (0x0a) character (never by CRLF sequence).
The log file format supports
Plain text logging
Signed plain text logging using either RSA-SHA1 or DSA-SHA1
Symmetrically encrypted logging using either 3DES or AES
Asymmetrically encrypted logging using RSA (or DSA?)
Signed and symmetrically encrypted logging
Signed and Asymmetrically encrypted logging
All activity and error log file lines have the following format (any one of the 3):
# comment SE HH CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC SE HH SIG OURTS SRCTS IP:PORT SUCCEID MID A7NID NID MM VVV RES OP PPP FMT
where
Log signing and encryption designator. In all cases the actual signing or encryption key is not identified on the log line. This will need to be determined out-of-band.
PlainPlain: not signed and not encrypted
RSA-SHA1 signed (x = any encryption)
DSA-SHA1 signed
SHA1 check-summed, but not signed (SSSS is the checksum)
Asymmetrically AES encrypted (x = any signing method)
Asymmetrically 3DES encrypted
Symmetrically AES encrypted (theoretical: how to safeguard the key?)
Symmetrically 3DES encrypted (theoretical: how to safeguard the key?)
Experimental arrangements.
HMAC chaining code to previous message, to protect against log line deletion. If not used, this will be "-".
Safe base64 encoded log encryption blob. In case of encryption blob, the rest of the log fields will not appear. Decrypted logline will contain fields starting from SSSS.
Safe base64 encoded log line signature blob. If no signature, this is a dash ("-").
Our time stamp, format YYYYMMDD-HHMMSS.TTT where TTT are the milliseconds. The time is always in GMT (UTC, Zulutime).
Source time stamp, format YYYYMMDD-HHMMSS.TTT. If TTT was not originally specified it is represented as "501". The time is always in GMT (UTC, Zulu-time).
The IP address and the port number of the other end point (usually client, but could be spoofed, caveat emptor).
The SHA1 name of the entity (succinct entity ID without the equals sign).
Message ID relating to the log line. Allows message to be fetched from the database or the file system. Any relates-to or similar ID is only available by fetching the original message. Dash ("-") if none.
Assertion ID relating to the log line. Allows assertion to be fetched from the database or the file system. If message benefits from multiple assertions, this is the one relating to the outermost one. Other A7NIDs are only available by fetching the original assertion. Dash ("-") if none. If the assertion is encrypted and can not be decrypted, then placehoder "-enca7n-" is used.
IdP assigned NameID relating to the message, if any. If the NameID is encrypted and can not be decrypted, then placeholder "-encnid-" is used.
Module or subsystem indicator (e.g. discriminate between SP and IdP that log to same file)
Signature validation codes
Signature issued ("Underwritten" - getit?).
Capital Oh (not zero). All relevant signatures validate (generally assertion)
Unsupported or bad signature or message digest algorithm
Checksum of XML DSIG does not validate
The RSA layer of the signature does not validate
No signature detected (or issued) or expected or not applicable.
Malformed signature, e.g. SignedInfo or Reference missing
Issuer metadata not found (or not in CoT, or corrupt metadata).
Assertion validity error (e.g. not in time range or wrong audience)
Operation failed or faulted by error code (low level protocol ok)
Extended signature validation code (generally error or failure)
Experimental signature validation code (generally failure)
Result of the operation.
Operation was success
Operation failed because client did not provide valid input
Operation failed due to server side error
Operation failed due to policy or permissions issue
Temporary error, client was encouraged to retry
Metadata related error (no metadata or parse error in metadata)
Redirect or recredential. Client was encouraged to retry.
Way point message. Neither success nor failure.
Extended result (generally error or failure)
Experimental result (generally failure)
The documented operation
New federation was created (usually due to SSO or discovery).
SP SSO using federated ID was performed
SP SSO using transient NameID was performed
IdP SSO using federated ID was issued
IdP SSO using transient NameID was issued
SP new session
IdP new session
WSP new session
Single Logout was completed (SP)
Single Logout completed (IdP)
Defederation was performed
Server configuration (/var/zxid/zxid.conf) is bad
No metadata found after options exhausted (cache, fetch from net)
Metadata parsing error
XML parsing error in protocol
SAML call failed (often SOAP call)
Missing element (in otherwise correct XML)
File missing, wrong permissions, corrupt content. Install errors.
Crypto or signature error, usually due to corrupt or wrong key.
Duplicate message. Suspect replay attack.
Other error
For WSP the OP is the command verb that was exercised.
Discovery: Issue of EPR with assertion using federated NameID
Discovery: Issue of EPR with assertion using transient NameID
Summary status of successful discovery on server side
Message was validated OK and accepted for processing. See zxid_wsp_validate()
Message was decorated and issued, see zxid_wsp_decorate()
Notification of issued message written in local audit trail
For WSC the OP is the command verb preceded by capital C, e.g. "CQuery".
Additional OP verbs may need to be specified for protocol substeps like artifact resolution (ART) and direct authentication (AUTH).
Artifact resolution request sent with SOAP (1)
Redirection with Authentication Request
Local Logout (1)
Redirection with Single Logout Request
Redirection with Single Logout Response
Redirection with Manage NameID Request for changing NameID
Redirection with Manage NameID Request for defederation
Single Logout Request SOAP call made
Manage NameID Request for changing NameID SOAP call
Manage NameID Request for defederation SOAP call
SAML call OK (often SOAP call)
Additional OP verbs may need to be specified for other logging operations like regular web access logs (HEAD, GET, POST).
IdP Selection screen is shown (2)
Management screen is shown (2)
Logged in (by SSO or session). Show protected content. arg is sid. (1)
SP Command Dispatch (received POST or redir) (2)
IdP Command Dispatch (received POST or redir) (2)
My metadata was served to requester on the net (1)
Getting metadata from net (2)
Got metadata from net (1)
Unknown CGI options (0, but not implemented yet)
Redirect or POST Bindong decoding
Authentication redirect
Authentication
Issuance of SSO Assertion
Issuance of SSO response
Issuance of Discovery Assertion
Issuance of Discovery response
Auto-Cert generation of a self-signed certificate
New user creation
Operation dependent one most relevant parameter. Dash ("-") if none.
Operation dependent free-form data. May contain spaces. Dash ("-") if none.
Logs are enabled in the config file zxidconf.h (compile time) by ZXLOG macros which provide default values for the log flags in struct zxid_conf. Each log flag is a bitmask of signing and encryption options. Zero value means no logging. "1" can be used to enable plain text logging.
Log signing may help you to argue that log evidence was (not) tampered with. You can configure the signing level in the config file zxidconf.h (compile time):
no signing (Px)
sha1 MD only (Sx)
RSA-SHA1 (Rx)
DSA-SHA1 (Dx)
For actual signing (options 2 and 3), the private key for signing must be available in /var/zxid/pem/logsign-nopw-cert.pem. Note that this file need not contain the actual certificate (but it may, it just will not be used).
The weak point of log signing is that if the private key is stolen, then someone can create falsified logs and the private key needs to be available on the point where the logs are generated - thus it is actually quite vulnerable.
Log encryption may help to keep the logs confidential. You can configure the configuration level in the config file zxidconf.h (compile time):
no encryption (xP)
RSA-AES (xA)
RSA-3DES (xT)
Symmetric AES (xB)
Symmetric 3DES (xU)
For RSA modes the public key for encryption must be available in /var/zxid/pem/logenc-nopw-cert.pem. Note that the private key should NOT be kept in this file: the whole point of public key encryption is that even if your server machine is stolen, the bad guys can't access the logs - if the private key was anywhere in the stolen machine, they will find it.
For symmetric encryption the key is the SHA1 hash of file /var/zxid/pem/logenc.key. Obviously this key must be kept secret, but see the caveat about stolen machine in the previous paragraph.
All encryption modes, except for 0, [RFC1951] zip compress the log line before encryption and safe-base64 encode the result of the encryption. All encryption modes, except 0 and 1, prefix the zipped log line with 128 bit nonce before encrypting.
The algorithm is roughly
If encrypt, zip the raw log line
If sign, compute the signature (over zipped version if applicable)
Prepend signature blob to log line. If encrypting, the signature is embedded in binary form, otherwise it is embedded in safe-base64 form.
If encrypt, perform the encryption.
If encrypt, apply safe-base64.
The supplied tool zxlogview(1) allows the logs to be decrypted and the signatures verified.
./zxlogview logsign-nopw-cert.pem logenc-nopw-cert.pem <some-log-lines
Note that for zxlogview(1) to work the logsign-nopw-cert.pem needs to contain the public key (and need not contain the privatekey) which is the opposite of the situation what zxid(1) needs to see in order to sign. Similarly logenc-nopw-cert.pem needs to contain the private key (and may contain the certificate, though this will not be used).
N.B. While encrypted logs are cool, you should evaluate the gain against the incovenience: if you encrypt them, the lesser mortal sysadmins may not be able to debug your installation because they do not know how to decrypt logs or you are not willing to trust them with the keys. For this reason, you can configure the encryption of error log separately.
For [RFC1951] zipped safe-base64 [RFC3548] output the input to base64 encoding is
LLSSSSZZZZZZZZZZZZZZ -- RFC1951 zipped safe-base64
For encrypted modes the input to AES (or other symmetric cipher) is
NNNNLLSSSSZZZZZZZZZZ -- Note how nonce is prepended
The NNNN is used as initialization vector and actual encryption encompasses LL, SSSS, and ZZZZ.
In RSA-AES the session key is encrypted using RSA and prepended to the input for base64 encoding.
KKEEEECCCCCCCCCCCCCC -- RSA-AES: note prepended session key
16 bytes of nonce. This is used as initialization vector
for AES or 3DES cipher operated in CBC mode.
Bigendian integer representing signature length in bytes.
0 means none. Negative values reserved for future use.
The signature in binary
Bigendian integer representing encrypted session key
length in bytes. Negative values are reserved for future use.
RSA encrypted session key in binary
Ciphertext from the symmetric cipher, including nonce.
In RSA operations RSA_PKCS1_OAEP_PADDING padding is used (PKCS #1 v2.0).
Logging of assertions is controlled by configuration options ZXLOG_ISSUE_A7N and ZXLOG_RELY_A7N. At least ZXLOG_RELY_A7N should be turned on for ID-WSF web services to work correctly. Logging relied assertions also allows detection of duplicate assertion IDs. Logging, or not, of issued assertions does not have any operational effect and is only for audit trail purposes.
Assertions are logged in directories depending on issuer's sha1 name.
/var/zxid/log/rely/ISSUER-SHA1-NAME/a7n/A7N-ID-AS-SHA1
Sha1 names are used to avoid any attack through issuer entity ID or the assertion ID being evilly crafted to contain shell metacharacters or filesystem significant characters.
Assertions issued by ourselves follow similar pattern
/var/zxid/log/issue/DEST-SHA1-NAME/a7n/A7N-ID-AS-SHA1
If the logfile starts by less-than character ("<") then it is in plain text. Encrypted or signed formats will start in another way, but are not specified at this time.
N.B. The relied-on assertions may be referenced from session objects and used in construction of credentials for ID-WSF based web services calls. Therefore the rely directory should not be cleaned too aggressively: the assertions must remain there until the referencing session expires.
Logging of requests and responses is controlled by ZXLOG_ISSUE_MSG and ZXLOG_RELY_MSG. Logging, or not, messages has no operational effect and is only for audit trail purposes. If logging of relied messages is turned on, then it is possible to detect duplicate message IDs.
Request messages are logged in directories depending on issuer's sha1 name.
/var/zxid/log/rely/ISSUER-SHA1-NAME/msg/REQ-ID-AS-SHA1
Sha1 names are used to avoid any attack through issuer entity ID or the assertion ID being evilly crafted to contain shell metacharacters or filesystem significant characters.
Responses issued by ourselves follow similar pattern
/var/zxid/log/issue/DEST-SHA1-NAME/msg/RESP-ID-AS-SHA1
If the logfile starts by less-than character ("<") then it is in plain text. Encrypted or signed formats will start in another way, but are not specified at this time.
The ZXID session system serves three purposes:
Remember whether user has logged in. The session ID is carried either in a cookie or as part of the URL.
Make it possible to perform Single Logout (SLO) and certain federation management tasks.
Remember the service end points (EPRs) that were either
supplied as bootstrap attributes in the SSO assertion, or
later discovered
The biggest complication is the requirement to remember the EPRs and the solution currently used is to keep them as files in a per session directory under the /var/zxid/ses tree.
/var/zxid/ | +-- zxid.conf Main configuration file +-- pem/ Our certificates +-- cot/ Metadata of CoT partners (metadata cache) +-- ses/ Sessions | | | +-- SESID/ Each session has its own directory | | | +-- .ses The session file | `-- SVC,SHA1 Each bootstrap is kept in its own file | +-- user/ Local user accounts (if enabled) | | | +-- SHA1/ Each local user has a directory whose name is SHA1 | | | of the user's NameID (idpnid) and IdP Entity ID | | +-- .mni Information needed by Name ID management | | +-- PS,SHA1 Long term People Service EPR, kept in its own file | | +-- .deleg/ Delegations (invitations) user has issued | | | | | | | +-- DELEG | | | `-- DELEG | | | | | +-- .access/ Invitations user has received (delegations to access other's resources) | | | | | | | +-- ACCESS | | | `-- ACCESS | | | | | +-- .bs/ Local user attribute directory | | | | | | | `-- .at Local user attributes as LDIF (see zxid_ses_to_pool()) | | | | | `-- .pw User's local password if any (usually none) | | | `-- SHA1b -> ../uid/Sue SHA1 can also be symlink to local account | +-- uid/ Local user ID (local login name) to SHA1 mapping | | | +-- joe -> ../user/SHA1 Symlink points to the real user directory | +-- Sue/ Local user can have directory whose name is the uid | | | +-- .mni Information needed by Name ID management | `-- .pw User's local password if any (usually none) | | `-- log/ Log files, pid files, and the like
The session ID is an unguessable (but see ID_BITS configuration options) safe base64 encoded pseudorandom number. Unguessability ensures that the session can only be crated via SSO.
The service EPRs are XML documents whose name is composed from two components
SVC,SHA1
The service type URI, with file system unsafe characters (e.g. "/" and ",") folded to underscore ("_"). Purpose of the SVC is to allow quick identification, without opening, of the files that contain EPRs for a given service type. Only first 200 bytes of the service type are used.
safe base64 encoded SHA1 hash of the content of the EPR. The purpose of the SHA1 hash is to produce a unique identifier so that two distinct EPRs for same service will have different file names.
The session directory also contains .ses file. The first line is as follows (still subject to change, Oct 2007):
NameID|a7n-ref
The pipey symbol (|) is a field separator. Future versions may define further fields beyound these original two. All other lines are reserved for future expansion. Fields:
NameID, extracted during SSO
Filesystem path to the SSO assertion.
User directories are used for storage of local account information. Since many web applications, to which ZXID may be integrated, already have their own local user storage, the ZXID user directory is optional, see USER_LOCAL configuration option.
IdP initiated ManageNameID requests depend on local user accounts, so if you want this to work you need to enable them. Local user account management may be useful on its own right if your application does not yet have such system. If it has, you probably want to continue to use the application's own system.
Another functionality that needs the local user accounts is delegation using people service. In this case the invitations / delegations and PS-EPR of the user are remembered.
Each user is represented by a directory whose filename is safe base64 of the SHA1 hash of the user's NameID and the IdP's Entity ID. The directory can actually be a symlink to some other place, such as uid/ directory, see below.
Inside the directory, a file called .mni captures the information needed for NameID Management. It is expected that other files about the user may be populated to capture other aspects. Your own applications could even create files here.
The first line of the .mni file is as follows
FMT|IDPEnt|SPqual|NameID|MNIptr
The pipey symbol (|) is a field separator. Future versions may define further fields beyound these original two. All other lines are reserved for future expansion. Fields:
NameID Format
IdP entity ID that qualifies the NameID (namespace if you like). This usually corresponds to the NameQualifier of
SP entity or affilitation ID (optionally) sent by IdP. This further qualifies the namespace of the Name ID.
NameID of the account
If NameID Management has been used to change the IdP assigned NameID, then the new NameID. There will be a local user account directory for the new NameID. Consider this as a sort of symlink functionality.
The main purpose of the local uid/ directory is to support local logins. Since the main objective of ZXID is to support Single Sign On, there should be little need to support local logins. Hence uid/ directory is optional.
Often uid/ directory is implemented by providing symlinks to the user/ directory. In this case uid/ only acts as an index or mapping from local UID to the safe base64 encoded SHA1 of the IdP assigned Name ID, see above.
zxididp uses local uid/ directory to implement the IdP logins and to store users federations, bootstraps, and attributes.
/var/zxid/ | +-- idpzxid.conf Main configuration file +-- idppem/ Our certificates +-- idpcot/ Metadata of CoT partners (metadata cache) +-- idpses/ Sessions | | | +-- SESID/ Each session has its own directory | | | +-- .ses The session file | `-- SVC,SHA1 Each bootstrap is kept in its own file | +-- idpuid/ Local user ID (local login name) to SHA1 mapping | | | +-- JOE/ Local user has directory whose name is the login uid | | | | | +-- .log Log of operations regarding the user | | +-- .pw User's local password | | +-- .yk User's yubikey shared aes128 secret in hex | | +-- .ykspent/ Cache of already used One TIme Passwords | | | | | | | `-- OTP File name is the spent Yubikey ticket (w/o uid) | | | | | +-- .bs/ Directory of bootstraps to be included | | | | | | | +-- .at Attributes to be included in each SSO | | | `-- SVC,SHA1 Bootstrap for a service | | | | | `-- SP,SHA1/ One directory for each SP user is federated with | | | | | +-- .mni Federated name id to be used with this SP | | +-- .at Attributes to be included for this SP | | `-- SVC,SHA1 Bootstrap to be included for this SP | | | `-- .all/ Template used for all users | | | +-- .bs/ Directory of default bootstraps to be included | | | | | +-- .at Attributes to be included in each SSO | | `-- SVC,SHA1 Bootstrap for a service | | | `-- SP,SHA1/ One directory for each SP | | | +-- .at Attributes to be included for this SP | `-- SVC,SHA1 Bootstrap to be included for this SP | +-- idpnid/ Index of federated NameIDs, to map to uid | | | `-- SVC,SHA1 Bootstrap to be included for this SP | | | `-- NID Content of the file is uid | +-- idpdimd/ | | | `-- SVC,SHA1 Discovery MD registration for a service | `-- idplog/ Log files, pid files, and the like
When generating SSO assertion, the attributes are collected as follows:
LDIF at /var/zxid/uid/JOE/.bs/.at
LDIF at /var/zxid/uid/JOE/SP,SHA/.at
LDIF at /var/zxid/uid/.all/.bs/.at
LDIF at /var/zxid/uid/.all/SP,SHA/.at
As of version 0.33 (20090904) the attributes are rendered singlevalued. If multiple occurrances of an attribute happen, the first instance is used and others ignored. However, in a future version, we expect to support multivalued attributes.
The order for attaching bootstrap attributes is similar.
Yubikey support works by using the initial part of the ticket (passed in as user field) as uid and the latter as the ticket proper. The uid part is used to locate correct directory. Mapping from yubikey modhex to real UID is done by creating a symlink. The AES128 shared (between yubikey token and IdP) key is kept in the .yk file. As this is not a password has, but rather directly the shared secret, it requires rigorous approach to the filesystem security. The fact that .pw and .yk are separate files caters for the possibility of user authenticating either by yubikey or by password. By default yubikey is one factor authentication (in fairly secure and very convenient form). If two factor authentication is desired, the password component should be prefixed to the UID component, i.e. first user types PIN and then presses yubikey to add UID and ticket.
TLS Client Certificate authentication of users has not been implemented yet, but in any case would be mainly implemented by configuration of web server to request such certificate and verify it. By the time zxid gets called, the client cert authentication will already have happened. HTTP Basic authentication works in similar way and we make no attempt to cater for it, although it can be used of configured separately (in the traditional way).
zxpasswd(8) is a user provisioning tool that allows creation of new accounts as well as manipulation of .pw and .yk files.
Copyright (c) 2010-2011 Sampo Kellomäki (sampo@iki.fi), All Rights Reserved. Copyright (c) 2006-2009 Symlabs (symlabs@symlabs.com), All Rights Reserved. Author: Sampo Kellomäki (sampo@iki.fi)
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.