DACS_AUTH_AGENT(8) | DACS Web Services and CGI | DACS_AUTH_AGENT(8) |
dacs_auth_agent — DACS delegated authentication service
dacs_auth_agent
[dacsoptions
]
This web service is part of the DACS suite.
The dacs_auth_agent web service is used to request DACS credentials outside of the usual DACS authentication procedure (see dacs_authenticate(8)). The client making the service request, whether a user agent or middleware, is considered to be an "agent" trusted by the jurisdiction that receives the request by virtue of having obtained DACS credentials and satisfying DACS access control rules that grant it access to this service. In other words, an agent simply requests credentials for a given identity from dacs_auth_agent and they are returned if an access control rule grants access and dacs_auth_agent is configured appropriately.
The agent's DACS credentials can be obtained through dacs_authenticate(8), dacs_auth_transfer(8), dacscred(1), dacscookie(1), or even dacs_auth_agent.
If the request is successful, credentials are returned to the client within an HTTP cookie. Credentials generated by this service can be distinguished from those created by one of the other methods.
Access control rules are responsible for expressing restrictions on the types of operations to be granted to various trusted agents. Access to this web service must not be granted without establishing and testing carefully crafted access control rules and appropriate configuration. By default, all access to this service is denied.
Much like Unix's su(1) command lets the superuser assume the Unix identity of any other user, this service provides a way for a privileged client to request credentials for a user known to the receiving jurisdiction. Any other credentials in the possession of the client remain in effect. Help desk personnel and system administrators can use this capability to assist users by temporarily impersonating a user without having to know the user's password, obtaining the user's client certificate, or following the user's usual authentication procedure.
The service can also be invoked to effectively import an identity that is recognized by the agent but possibly not known to the receiving jurisdiction. This provides a way to convert foreign credentials, whether from a non-DACS based system or a different DACS federation, into credentials understood by the federation of the receiving jurisdiction. It is only necessary for the agent to understand the foreign credentials; DACS never sees them.
Another use of this service is in conjunction with middleware that does its own authentication. Having authenticated a user, an application can ask dacs_auth_agent for DACS credentials for the user.
In addition to the standard CGI arguments, dacs_auth_agent understands the following CGI arguments:
USERNAME
If present, the agent asserts that
USERNAME
is in some sense known to this jurisdiction.
ALIEN_FEDERATION
If present, the agent asserts that
ALIEN_USERNAME
, which must be provided, is
associated with the named external system.
This can be any string comprised of characters
allowed in a DACS username; presumably the agent
and DACS jurisdiction have agreed on the name to use.
This name, or a string mapped from it, will be incorporated into the resulting
DACS username and credentials.
ALIEN_USERNAME
If present, the ALIEN_FEDERATION
argument must also be given.
The agent asserts that the given name, relative to
ALIEN_FEDERATION
, has been authenticated.
This can be any string comprised of characters
allowed in a DACS username.
This name, or a string mapped from it, will be incorporated into the resulting
DACS username and credentials.
DACS_JURISDICTION
This identifies the receiving jurisdiction.
DACS_BROWSER
This optional parameter is as described for the dacs_authenticate(8) service.
OPERATION
This optional parameter is as described for the dacs_authenticate(8) service.
COOKIE_SYNTAX
This optional parameter is as described for the dacs_authenticate(8) service.
There are two modes of operation.
In local mode
,
the USERNAME
argument is provided
and is purported to be the DACS username of a user
known to the receiving jurisdiction.
The second mode, called alien mode
, is selected
if both an ALIEN_FEDERATION
argument and an
ALIEN_USERNAME
argument are present.
It is an error if only one of these arguments is given,
and the USERNAME
is ignored.
The mode checks that the ALIEN_FEDERATION
and
the ALIEN_USERNAME
relative to it are satisfactory.
This is done by requiring the ALIEN_FEDERATION
to
be recognized by the receiving jurisdiction; it may optionally be mapped
to a different string.
Similarly, the ALIEN_USERNAME
argument must be
recognized, relative to ALIEN_FEDERATION
or the
string mapped from it.
Credentials that have been designated as an
ADMIN_IDENTITY
will be returned only if the
AUTH_AGENT_ALLOW_ADMIN_IDENTITY
configuration
directive has the value "yes
".
Refer to
dacs.conf(5)
for a description of these configuration directives.
A revocation test is always performed on the DACS identity; see dacs.acls(5) for a description of how authentication revocation works.
If the USERNAME
argument is provided,
it must consist of printable characters, as determined by
isprint(3).
By default, dacs_auth_agent will blindly
accept the trusted client's assertion that USERNAME
is known to the receiving jurisdiction.
An administrator can constrain USERNAME
, however,
and optionally map it into a replacement that is a valid
DACS username.
If the virtual filestore item type
"auth_agent_local
" is configured, it is expected to
name a file consisting of expressions,
one per line (a continued line ends with a backslash).
Each expression is evaluated in turn until one returns a non-empty string
value; this value,
which must be a syntactically correct DACS username,
becomes the mapped username.
An evaluation error is fatal.
The value of the USERNAME
argument is available to
each expression as
${Expr::_}
(reminiscent of Perl's $_
variable).
For example, consider the configuration directive:
VFS "[auth_agent_local]dacs-fs:/usr/local/dacs/auth_agent_local_users"
and the file /usr/local/dacs/auth_agent_local_users, which contains:
regsub(${Expr::_}, "^auggie doggie$", "auggie") regsub(${Expr::_}, "^julia$", "sara") strtr(regsub(${Expr::_}, \ "\([^:]*\)://\([^.]*\)\\.\(.*\)", '${1}-${2}@${3}'), \ "A-Z", "a-z")
If USERNAME
is "auggie doggie
",
credentials will be issued for "auggie
".
If USERNAME
is "julia
",
credentials will be issued for "sara
".
If USERNAME
is
"https://Bob.Example.com
",
the third expression will return the string
"https-bob@example.com
",
which will become the mapped name (this example is apropos of mapping
OpenID names).
When configured, roles are obtained for USERNAME
in the same way as is done for
dacs_authenticate(8).
The alien mode of operation proceeds as follows:
It looks up ALIEN_FEDERATION
using
item type auth_agent_federations
.
When forming a key, the lookup operation will percent-encode
any ':
' and '%
' characters in
ALIEN_FEDERATION
, so the same encoding is required for
keys that appear in auth_agent_federations
.
If it is not found, authentication fails.
If found, it may optionally have a value; that value
will be used within the resulting DACS credentials
instead of the ALIEN_FEDERATION
argument.
In any case, the resulting value must be valid for
a DACS username.
It looks up ALIEN_USERNAME
using
an item type constructed by prepending the string
"auth_agent_federation_
" to the federation name derived
during the previous step.
When forming a key, the lookup operation will percent-encode
any ':
' and '%
' characters in
ALIEN_USERNAME
, so the same encoding is required for
stored keys.
If it is not found, authentication fails.
If found, it may optionally have a value; that value will be used
within the resulting DACS credentials
instead of the ALIEN_USERNAME
argument.
In any case, the resulting string must be valid for
a DACS username.
A DACS username will be formed using the federation name and username strings derived in the previous steps.
The following is an example of local mode operation. Assume the following configuration directive is in effect:
VFS "[auth_agent_local]dacs-fs:/usr/local/dacs/auth_agent_local_users"
Also assume that the file /usr/local/dacs/auth_agent_local_users contains the expression:
regsub(${Expr::_}, \ "\([^:]*\)://\([^.]*\)\\.\(.*\)", '${1}-${2}@${3}')
If a request is made with USERNAME
equal to
"http://Bob.Example.com
",
new credentials will be issued for
"http-Bob@Example.com
"
relative to the current jurisdiction.
The following is an example of alien mode operation. Assume the following configuration directives are in effect:
VFS "[auth_agent_federations]dacs-kwv-fs:/usr/local/dacs/auth_agent_feds" VFS "[auth_agent_federation_mars]dacs-kwv-fs:/usr/local/dacs/auth_agent_fed_mars"
Also assume that the file /usr/local/dacs/auth_agent_feds consists of the line
MARS:
and the file /usr/local/dacs/auth_agent_fed_mars consists of the line
gazoo:
If a request is made with ALIEN_FEDERATION
equal to "MARS
" and
ALIEN_USERNAME
equal to "gazoo
",
the request will satisfy alien mode's rules of operation with
the strings "MARS
" and "gazoo
"
being used to form the DACS username relative
to the current jurisdiction (DACS_JURISDICTION
).
If instead ALIEN_FEDERATION
were
"http://example.com
"
and the file
/usr/local/dacs/auth_agent_feds
looked like:
http%3A//example.com:example
then the string "example
" would be used with
"gazoo
" to form the
DACS username.
The word "alien
" is used because it sounds
cooler than "foreign
" and is arguably easier to spell.
A superficially similar feature called "affiliated DACS federations", which provides single sign-on across federation boundaries, is sometimes a more appropriate solution; see dacs_auth_transfer(8).
It should be possible for keys that are matched against
USERNAME
to be regular expressions and for the corresponding replacement values to
interpolate matched substrings.
dacs_authenticate(8), dacs_auth_transfer(8), dacs_current_credentials(8), dacs_signout(8), dacs.exprs(5), dacscred(1), dacscookie(1).
Copyright © 2003-2024 Distributed Systems Software.
See the
LICENSE
file that accompanies the distribution
for licensing information.
DACS Version 1.4.52 | 24-Sep-2024 | DACS_AUTH_AGENT(8) |
Table of Contents |
Font:
|
−− | Set | ++ |
$Id: dacs_auth_agent.8.xml 3304 2024-04-03 23:00:19Z brachman $