|DACS_MANAGED_INFOCAR(8)||DACS Web Services Manual||DACS_MANAGED_INFOCAR(8)|
NAME¶dacs_managed_infocard - create a managed Information Card
DESCRIPTION¶This program is part of the DACS suite.
The dacs_managed_infocard web service is used to create and register a managed InfoCard so that it can be used for authentication or other purposes. InfoCard-based authentication is performed by local_infocard_authenticate, a DACS authentication module.
A managed InfoCard must be registered by dacs_managed_infocard before it can be used by DACS. After registration, use dacs_infocard(8) or dacsinfocard(1) to administer self-issued or managed InfoCards.
There are several operational modes, determined by the MODE argument. In a self-serve mode, an authenticated user requests a managed InfoCard (with various limitations imposed); the new InfoCard is either sent directly to the user's browser or written to a file that the user can access in a separate operation. In an administrative mode, a DACS administrator requests a managed InfoCard on behalf of a user and is responsible for directing it to the user in a separate, secure operation.
There are many configuration directives associated with managed InfoCards. One of the most important is INFOCARD_STS_AUTH_TYPE, which determines the authentication method ("credential type") used between an Identity Selector, such as CardSpace, and the managed InfoCard's Identity Provider/Secure Token Service (IP/STS), such as dacs_sts(8). The following authentication methods are prescribed by the InfoCard specification:
An Identity Selector will display all claim values returned to it by an Identity Provider. An Identity Provider must therefore employ cryptographic methods to obtain privacy or check authenticity with respect to claim values.
Accounts are accessed through DACS's virtual filestore using item type infocards. It is assumed that file permissions on the account database are such that all access is limited to the administrator, local_infocard_authenticate, dacs_infocard(8), and dacs_sts(8).
Configuration¶The following configuration variables are available:
Web Service Arguments¶In addition to the standard CGI arguments, dacs_managed_infocard understands the following CGI arguments:
An identity is always associated with these InfoCards using a claim named dacs_identity in the DACS namespace (http://dacs.dss.ca/claims). By default, the identity used is that of the requestor. An administrator may instead specify the identity using the INFOCARD_IDENTITY argument, which need only be a syntactically valid DACS identity.
The caller may specify from zero to a compile-time maximum number of claims (MIC_MAX_STATIC_CLAIMS, 10). A privatepersonalidentifier (PPID) is always created automatically, so any user request for that claim is ignored. Only a DACS administrator may define the dacs_identity claim in the DACS namespace; if present, it must be a syntactically valid DACS identity. Therefore, only a DACS administrator may use this mode to create an InfoCard that can be used for DACS authentication. Similiarly, only a DACS administrator may define the dacs_roles claim in the DACS namespace; if present, it must be a syntactically valid role descriptor string.
The claims are specified by up to MIC_MAX_STATIC_CLAIMS arguments (not counting any PPID claims) of the form CLAIM_num_type, where num starts at one and continues with consecutive integers and type is:
The DACS namespace is reserved for use by DACS and identifies claim types with semantics that are defined by DACS.
The optional argument CLAIM_URI has the same syntax as a CLAIM_num_URI argument and establishes a default URI that will be used if any CLAIM_num_URI argument is missing or is the empty string.
The optional argument CARD_NAME assigns a name to the InfoCard, which will be displayed by an Identity Selector.
The first missing or null-string-valued CLAIM_num_NAME or CLAIM_num_VALUE argument indicates the end of the list. For example, if two claims are defined, the following arguments might be passed: CLAIM_1_NAME, CLAIM_1_VALUE, CLAIM_1_URI, CLAIM_1_LABEL, CLAIM_1_DESC, CLAIM_2_NAME, CLAIM_2_VALUE, CLAIM_2_URI, CLAIM_2_LABEL, and CLAIM_2_DESC. Any syntactical or length violation causes a fatal error.
DIAGNOSTICS¶The program exits 0 if everything was fine, 1 if an error occurred.
BUGS¶It is currently not possible to just register a managed InfoCard (you must create and register it), so you cannot import a card.
Once a managed InfoCard is created, most of its characteristics cannot be changed. There should be a way to "refresh" a managed InfoCard that has expired or otherwise become invalid.
The various constraints on claim types should probably be run-time configurable, or possibly done away with altogether. The specification imposes no limits on them.
There should be a web service and utility to allow creation of a self-issued InfoCard (which may then be imported into a user's Identity Selector).
In 2011, Microsoft announced that Windows CardSpace 2.0 will not be shipped and they will offer a new technology called U-Prove.
SEE ALSO¶dacsinfocard(1), dacs.conf(5), dacs_authenticate(8), dacs_infocard(8), dacs_mex(8), dacs_sts(8), Using InfoCards With DACS
AUTHOR¶Distributed Systems Software (www.dss.ca)
COPYING¶Copyright © 2003-2018 Distributed Systems Software. See the LICENSE file that accompanies the distribution for licensing information.
- configuration directives
- standard CGI arguments
- VFS URI
- FORMAT argument
- claim information
- role descriptor string
- Using InfoCards With DACS