dacs_infocard - Information Card administration
dacs_infocard [dacsoptions[1]]
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.
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.
•
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>
The program exits 0 if everything was fine, 1 if an error
occurred.
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].
Distributed Systems Software (www.dss.ca[19])
Copyright © 2003-2012 Distributed Systems Software. See the
LICENSE[20] file that accompanies the distribution for licensing
information.
- 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