bionic (8) dacs_infocard.8.gz

Provided by: dacs_1.4.38a-2build1_amd64 bug

NAME

       dacs_infocard - Information Card administration

SYNOPSIS

       dacs_infocard [dacsoptions[1]]

DESCRIPTION

       This program is part of the DACS suite.

       The dacs_infocard web service is used:

       •   to perform a variety of administrative InfoCard functions;

       •   as a Relying Party to register a self-issued InfoCard, creating an account that can be used for
           authentication. InfoCard-based authentication is performed by local_infocard_authenticate[2], a DACS
           authentication module. These accounts are used only by local_infocard_authenticate and are completely
           separate from any other accounts.

       •   to act on behalf of a Relying Party to validate and extract claim values from a secure token created
           from either a self-issued or managed InfoCard.

           Notes
           •   Many Identity Selectors can create a self-issued InfoCard, but you must use
               dacs_managed_infocard(8)[3] to create a managed InfoCard.

           •   If a Relying Party checks that the security token that it receives satisfies the validity window
               condition expressed by the token, as it typically will, then the system clocks at the IP/STS
               (e.g., dacs_sts(8)[4]) and Relying Party must be adequately synchronized; see
               INFOCARD_TOKEN_DRIFT_SECS[5].

           •   Owing to the InfoCard system architecture, a Relying Party need not have network connectivity to
               a user's IP/STS (e.g., dacs_sts(8)[4]), although the user's browser must. This means, for
               example, that if a user (or his organization) operates his own IP/STS, it can be located on the
               same side of a firewall as the user's browser, which may improve the level of security of the
               IP/STS and any sensitive information it may store and access.

           •   Much of the functionality of this program is also available as a DACS utility,
               dacsinfocard(1)[6], which operates on the same account files.

       Accounts are accessed through DACS's virtual filestore using item type infocards.

           Note
           The official nomenclature for claims can be confusing. In an attempt at consistency and
           simplification, the DACS documentation tries to adhere to the following definitions (with the stated
           compile-time limits):

           Claim
               A pair comprising an attribute name (the Claim type) and an attribute value (the Claim value).
               The attribute value is optional. The number of claims is limited to 10 static claims and 20
               dynamic claims.

           Claim type
               A unique URI[7] that consists of a Claim URI prefix followed by a Claim name. This can be thought
               of as an attribute name.  DACS does not allow the URI to include a query or fragment component. A
               claim type is never dereferenced, it is merely a label. Only characters that are valid in a URI
               are allowed; therefore any invalid characters must be properly encoded. Claim types are case
               sensitive, despite the fact that they are URIs. There is a compile-time length limit: 128
               characters for the URI prefix and 32 characters for the claim name.

           Claim URI prefix
               This URI identifies a namespace in which the Claim name lives (it may not include a query or
               fragment component). Two claim types[8] with different URI prefixes but the same claim name are
               distinct. The InfoCard specification uses the namespace
               http://schemas.xmlsoap.org/ws/2005/05/identity/claims for self-issued claims.  DACS uses the
               namespace http://dacs.dss.ca/claims for its claims. These namespaces should be treated as
               "reserved". User-defined claims should live in other namespaces, preferably ones over which the
               user has some authority.

           Claim URI prefix abbreviation
               To avoid the tedious and error-prone task of having to repeatedly enter long Claim URI prefix
               strings, in designated contexts DACS recognizes (but never requires) an abbreviation. Two
               case-sensitive abbreviations are defined: "standard" (equivalent to
               http://schemas.xmlsoap.org/ws/2005/05/identity/claims) and "dacs" (equivalent to
               http://dacs.dss.ca/claims).

           Claim name
               This is a URI path component. When appended to a Claim URI prefix (or paired with a Claim URI
               prefix abbreviation), it forms a Claim type. Only characters that are valid in a URI path
               component are allowed. It is limited to 32 characters.

           Claim value
               This can be thought of as an attribute value. Technically, this is defined as an xs:string[9],
               which is a sequence of XML characters[10]. Claim values are limited to 64 characters.

OPTIONS

   Web Service Arguments
       In addition to the standard CGI arguments[11], dacs_infocard understands the following CGI arguments:

       OPERATION
           The following operations are supported:

           •   DELETE

               Delete the account associated with USERNAME. This effectively revokes the InfoCard; a self-issued
               InfoCard may be re-registered, but a managed InfoCard becomes unusable.

                   Note
                   The quickest way to delete all accounts is to delete the contents of the infocards item type;
                   e.g., if infocards points to a file, remove the file or copy /dev/null to it.

           •   DISABLE

               Disable the account associated with USERNAME. InfoCard-based authentication on this account will
               fail; this revokes the InfoCard, but in a reversible way. The request is successful if the
               account is already disabled.

           •   ENABLE

               Enable the existing account associated with USERNAME. InfoCard-based authentication on this
               account will be possible. The request is successful if the account is already enabled.

           •   LIST

               List all accounts.

           •   REGISTER

               Register or re-register the submitted InfoCard. Exactly one set of credentials must accompany the
               request, and if registration is successful, the submitted InfoCard becomes associated with that
               identity.

           •   TOKEN_ATTRVALS

               If the submitted token is valid, display each claim (attribute) value associated with the
               ATTRLIST argument, which consists of zero or more claim names separated by a space. If ATTRLIST
               is absent or the empty string, all claims in the token are displayed (note that this is not
               necessarily all of the claims associated with the InfoCard). If any requested claim is not found,
               the request is ignored (i.e., it is not an error). The privatepersonalidentifier claim is
               displayed in the friendly identifier syntax rather than as a base-64 encoded string. The InfoCard
               (self-issued or managed) does not need to be registered at the jurisdiction.

               Three syntaxes are recognized for a claim name. Some claims are "predefined" in that they are
               available in any valid token: issuer, confirm_method, ppid (or privatepersonalidentifier),
               exponent (self-issued only), and modulus (self-issued only). The second syntax is the full claim
               URI (e.g., http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage). The third syntax uses
               the DACS shorthand: the word "standard" or "dacs", a colon, and the claim name (e.g.,
               standard:webpage). The token is searched for each claim in the ATTRLIST, other than the
               predefined ones.

                   Note
                   Only the full URI syntax can be used to identify claims in an HTML OBJECT's requiredClaims
                   and optionalClaims param tag.

           •   TOKEN_VALIDATE

               Parse the submitted token and test whether it is valid.

       xmlToken
       AUXILIARY
           This is the submitted InfoCard. It is required for the TOKEN_VALIDATE, TOKEN_ATTRVALS, and REGISTER
           operations. The AUXILIARY parameter name may only be used for this purpose if the xmlToken parameter
           name is not also used.

       FORMAT
           By default, output is emitted in HTML. Several varieties of XML output can be selected, however,
           using the FORMAT argument (please refer to dacs(1)[12] and dacs_passwd.dtd[13]). A FORMAT of plain
           may be useful for programs that need to extract claim values; claims are listed one per line with the
           claim type, followed by an "=", followed by the claim value.

       USERNAME
           For some operations, the name of the account to act on.

       For the DELETE, DISABLE, and ENABLE operations, the request must be submitted by the account's owner or
       the DACS administrator.

       Here is an example of a form that might be used to register a self-issued InfoCard:

           <form name="reg_form" id="reg_form" method="post" action="/cgi-bin/dacs/dacs_infocard">
           <table>
           <tr>
           <td>
            <img src="/infocards/ic_image.jpg" onClick="reg_form.submit()"/>
           <object type="application/x-informationCard" name="xmlToken">
            <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
            <param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self">
            <param name="requiredClaims"
             value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier">
            <param name="privacyUrl" value="https://example.com/infocards/privacy_statement.txt">
            <param Name="privacyVersion" value="3">
           </object>
           </td>
           </tr>
           <tr>
           <td align="center">
            <input type="submit" name="infocard_register" value="Register" id="infocard_register" />
           </td>
           <td>
           </td>
           </table>
           <input type="hidden" name="OPERATION" value="REGISTER">
           </form>

FILES

       dacs_infocard.css[14]

DIAGNOSTICS

       The program exits 0 if everything was fine, 1 if an error occurred.

BUGS

       The compile-time limits are fairly arbitrary and only exist to thwart abuse. It should probably be
       possible to specify them at run-time instead.

       XML output is not available yet.

       Registration of a self-issued InfoCard uses the card's PPID (Private Personal Identifier), which differs
       for a given InfoCard for different Relying Parties. The specification does not precisely define how two
       Relying Party endpoints are compared for equality, but if an identity selector decides that a
       jurisdiction's endpoint has changed (e.g., its domain name has been reconfigured), all self-issued
       InfoCards previously registered at the jurisdiction will become unusable until they are re-registered.

       This functionality should be integrated with dacs_admin(8)[15].

SEE ALSO

       dacsinfocard(1)[6], dacs.conf(5)[16], dacs_authenticate(8)[17], dacs_managed_infocard(8)[3], Using
       InfoCards With DACS[18]

AUTHOR

       Distributed Systems Software (www.dss.ca[19])

COPYING

       Copyright2003-2012 Distributed Systems Software. See the LICENSE[20] file that accompanies the
       distribution for licensing information.

NOTES

        1. dacsoptions
           http://dacs.dss.ca/man/dacs.1.html#dacsoptions

        2. local_infocard_authenticate
           http://dacs.dss.ca/man/dacs_authenticate.8.html#local_infocard_authenticate

        3. dacs_managed_infocard(8)
           http://dacs.dss.ca/man/dacs_managed_infocard.8.html

        4. dacs_sts(8)
           http://dacs.dss.ca/man/dacs_sts.8.html

        5. INFOCARD_TOKEN_DRIFT_SECS
           http://dacs.dss.ca/man/dacs.conf.5.html#INFOCARD_TOKEN_DRIFT_SECS

        6. dacsinfocard(1)
           http://dacs.dss.ca/man/dacsinfocard.1.html

        7. URI
           http://www.rfc-editor.org/rfc/rfc3986.txt

        8. claim types
           http://dacs.dss.ca/man/#claim_types

        9. xs:string
           http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string

       10. XML characters
           http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char

       11. standard CGI arguments
           http://dacs.dss.ca/man/dacs.services.8.html#standard_cgi_args

       12. dacs(1)
           http://dacs.dss.ca/man/dacs.1.html

       13. dacs_passwd.dtd
           http://dacs.dss.ca/man/../dtd-xsd/dacs_passwd.dtd

       14. dacs_infocard.css
           http://dacs.dss.ca/man//css/dacs_infocard.css

       15. dacs_admin(8)
           http://dacs.dss.ca/man/dacs_admin.8.html

       16. dacs.conf(5)
           http://dacs.dss.ca/man/dacs.conf.5.html

       17. dacs_authenticate(8)
           http://dacs.dss.ca/man/dacs_authenticate.8.html

       18. Using InfoCards With DACS
           http://dacs.dss.ca/man/using-infocards-with-dacs.html

       19. www.dss.ca
           http://www.dss.ca

       20. LICENSE
           http://dacs.dss.ca/man/../misc/LICENSE