โดย voip4share » 20 ธ.ค. 2009 12:49
10. Authentication Configuration
10.1 หัวข้อ [Gatekeeper::Auth]
The section defines the authentication mechanism for the gatekeeper.
Syntax:
authrule=actions
<authrule> := SimplePasswordAuth | AliasAuth | FileIPAuth | PrefixAuth | RadAuth | RadAliasAuth | SQLAuth | SQLAliasAuth | SQLPasswordAuth | CapacityControl | ...
<actions> := <control>[;<ras>|<q931>,<ras>|<q931>,...]
<control> := optional | required | sufficient | alternative
<ras> := GRQ | RRQ | URQ | ARQ | BRQ | DRQ | LRQ | IRQ
<q931> := Setup | SetupUnreg
A rule may results in one of these three codes: ok, fail, next.
ok - The request is authenticated by this module.
fail - The authentication fails and should be rejected.
next - The rule cannot determine the request.
There are also three ways to control a rule:
optional - If the rule cannot determine the request or accepts it, it is passed to next rule. Otherwise processing stops and the request is rejected.
required - The requests should be authenticated by this module, or it would be rejected. The authenticated request would then be passed to next rule.
sufficient - If the request is authenticated, it is accepted, or it would be rejected. That is, the rule determines the fate of the request. No rule should be put after a sufficient rule, since it won't take effect.
alternative - similar to the sufficient rule, except that if the module cannot determine request fate, the request is passed to a next module.
Currently supported modules: (most only support a subset of the ras or q931 actions)
SimplePasswordAuth/SQLPasswordAuth/H350PasswordAuth
These modules check the tokens or cryptoTokens fields of RAS message. The tokens should contain at least generalID and password. For cryptoTokens, cryptoEPPwdHash tokens hashed by simple MD5 and nestedcryptoToken tokens hashed by HMAC-SHA1-96 (libssl must be installed!) are now supported. For tokens tokens hashed by CAT (Cisco Access Token) and a clear text username/password are now supported. The ID and password are read from [SimplePasswordAuth] section, or a SQL database for SimplePasswordAuth and SQLPasswordAuth modules. The MySQLPasswordAuth module is supported for backward compatibility. For H.350.2 authentication (H350PasswordAuth) the GkH350::Settings section connection information must be completed.
AliasAuth/SQLAliasAuth
The module can only be used to authenticate RegistrationRequest (RRQ). The IP of an endpoint with a given alias should match a specified pattern. For AliasAuth the pattern is defined in [RasSrv::RRQAuth] the section. For SQLAliasAuth, the pattern is retrieved from a SQL database as defined in the [SQLAliasAuth] section.
FileIPAuth
This module provides a simple way to restrict access to the gatekeeper based on caller's IP or network.
PrefixAuth
The IP or aliases of a request with a given prefix must match a specified pattern. See section [PrefixAuth] for details. Currently the module can only authorize AdmissionRequest (ARQ) and LocationRequest (LRQ).
RadAuth
Provides authentication based on H.235 username/password security scheme. Authenticates RRQ, ARQ and Q.931 Setup through remote RADIUS servers. It passes to RADIUS servers the usernames and passwords extracted from CAT (Cisco Access Tokens) tokens carried inside RRQ, ARQ or Setup packets. Therefore if your endpoints do not support CATs or you do not need an authentication scheme based on individually assigned usernames/password then this module would not be appropriate (but you may check the RadAliasAuth module). See section [RadAuth] for details.
RadAliasAuth
Provides authentication based on endpoint aliases and/or call signaling IP addresses with remote RADIUS servers. It does not need any H.235 tokens inside RAS messages, so it can be used on a wider range of systems as compared to RadAuth. RRQ, ARQ and Q.931 Setup messages can be authenticated using this module. See section [RadAliasAuth] for details.
SQLAuth
A powerful module to authenticate and authorize RRQ, ARQ, LRQ and Setup messages. It can perform checks based on various parameters such as caller's number, destination number, username and more. It also supports enforcing call duration limit, number rewriting, call routing, alias verification and assignment. See section [SQLAuth] for more details.
CapacityControl
A flexible module to control inbound call volume with ability to configure various conditions. IMPORTANT: It must be used in conjunction with the CapacityControl accounting module. See section [CapacityControl] for more details.
You can also configure a rule to check only for specific RAS messages. The following example configures SimplePasswordAuth as an optional rule to check RRQ and ARQ. If a RRQ is not checked (does not contain tokens or cryptoTokens fields), it is checked by AliasAuth. The default is to accept all requests.
Example 1:
SimplePasswordAuth=alternative;RRQ,ARQ
AliasAuth=sufficient;RRQ
The example below authenticates all calls, checking signaling Setup message details, using the RadAliasAuth module.
Example 2:
RadAliasAuth=required;Setup
default=allow
This example checks endpoint registrations (RRQ) and call admissions (ARQ) either by means of username/password (RadAuth) or alias/IP (RadAliasAuth). Additionally, if the call is from an unregistered endpoint (and therefore no RRQ or ARQ authentication has been performed), Setup message authentication using RadAliasAuth takes place (SetupUnreg).
Example 3:
RadAuth=alternative;RRQ,ARQ
RadAliasAuth=alternative;RRQ,ARQ,SetupUnreg
default=reject