my $csr = Net::OpenID::Consumer->new( %options );
The following option names are recognized: ua, cache, args, consumer_secret, minimum_version, required_root, assoc_options, and nonce_options in the constructor. In each case the option value is treated exactly as the argument to the corresponding method described below under Configuration.
$csr-><B>messageB>($key) Returns the value for the given key/field from the OpenID protocol message contained in the request URL parameters (i.e., the value for the URL parameter openid.$key). This can only be used to obtain core OpenID fields not extension fields.
Calling this method without a $key argument returns a Net::OpenID::IndirectMessage object representing the protocol message, at which point the various object methods are available, including
$csr->message->protocol_version $csr->message->has_ext $csr->message->get_ext
$csr-><B>errB> Returns the last error, in form errcode: errtext, as set by the various handlers below. $csr-><B>errcodeB> Returns the last error code. See Error Codes below. $csr-><B>errtextB> Returns the last error text. $csr-><B>json_errB> Returns the last error code/text in JSON format.
$csr-><B>uaB>($user_agent) $csr-><B>uaB> Getter/setter for the LWP::UserAgent (or subclass) instance which will be used when direct HTTP requests to a provider are needed. Its highly recommended that you use LWPx::ParanoidAgent, or at least read its documentation so youre aware of why you should care. $csr-><B>cacheB>($cache) $csr-><B>cacheB> Getter/setter for the cache instance which is used for storing fetched HTML or XRDS pages, keys for associations with identity providers, and received response_nonce values from positive provider assertions.
Setting a cache instance is not absolutely required, But without it, provider associations will not be possible and the same pages may be fetched multiple times during discovery. <B>It will also not be possible to check for repetition of the response_nonce, which may then leave you open to replay attacks.B>
$csr-><B>consumer_secretB>($scalar) $csr-><B>consumer_secretB>($code) $code = $csr->B<consumer_secret>; ($secret) = $code->($time);
The consumer secret is used to generate self-signed nonces for the return_to URL, to prevent spoofing.
In the simplest (and least secure) form, you configure a static secret value with a scalar. If you use this method and change the scalar value, any outstanding requests from the last 30 seconds or so will fail.
You may also supply a subref that takes one argument, $time, a unix timestamp and returns a secret.
Your secret may not exceed 255 characters.
For the best protection against replays and login cross-site request forgery, consumer_secret should additionally depend on something known to be specific to the client browser instance and not visible to an attacker. If SSH_SESSION_ID is available, you should use that. Otherwise youll need to set a (Secure) cookie on the (HTTPS) page where the signin form appears in order to establish a pre-login session, then make sure to change this cookie upon successful login.
$csr-><B>minimum_versionB>(2) $csr-><B>minimum_versionB> Get or set the minimum OpenID protocol version supported. Currently the only useful value you can set here is 2, which will cause 1.1 identifiers to fail discovery with the error protocol_version_incorrect and responses from version 1 providers to not be recognized.
In most cases youll want to allow both 1.1 and 2.0 identifiers, which is the default. If you want, you can set this property to 1 to make this behavior explicit.
$csr-><B>argsB>($ref) $csr-><B>argsB>($param) $csr-><B>argsB> Can be used in 1 of 3 ways:
1. Set the object from which URL parameter names and values are to be retrieved:
$csr->args( $reference )
If you pass in a CODE ref, it must,
o given a single parameter name argument, return the corresponding parameter value, and, o given no arguments at all, return the full list of parameter names from the request.
If you pass in an Apache (mod_perl 1.x interface) object and this is a POST request, you must not have already called $r->content as this routine will be making said call itself in order to extract the request parameters.
2. Get a parameter value:
my $foo = $csr->args("foo");
When given an unblessed scalar, it retrieves the value. It croaks if you havent defined a way to get at the parameters.
Most callers should instead use the message method above, which abstracts away the need to understand OpenIDs message serialization.
3. Get the parameter getter:
my $code = $csr->args;
this being a subref that takes a parameter name and returns the corresponding value.
$csr-><B>required_rootB>($url_prefix) $csr-><B>required_rootB> Gets or sets the string prefix that, if nonempty, all return_to URLs must start with. Messages with return_to URLS that dont match will be considered invalid (spoofed from another site). $csr-><B>assoc_optionsB>(...) $csr-><B>assoc_optionsB> Get or sets the hash of parameters that determine how associations with identity providers will be made. Available options include:
assoc_type Association type, (default HMAC-SHA1) session_type Association session type, (default DH-SHA1) max_encrypt (boolean) Use best encryption available for protocol version for both session type and association type. This overrides session_type and assoc_type session_no_encrypt_https (boolean) Use an unencrypted session type if the ID provider URL scheme is https:. This overrides max_encrypt if both are set. allow_eavesdropping (boolean) Because it is generally a bad idea, we abort associations where an unencrypted session over a non-SSL connection is called for. However the OpenID 1.1 specification technically allows this, so if that is what you really want, set this flag true. Ignored under protocol version 2. $csr-><B>nonce_optionsB>(...) $csr-><B>nonce_optionsB> Gets or sets the hash of options for how response_nonce should be checked.
In OpenID 2.0, response_nonce is sent by the identity provider as part of a positive identity assertion in order to help prevent replay attacks. In the check_authentication phase, the provider is also required to not authenticate the same response_nonce twice.
The relying party is strongly encouraged but not required to reject multiple occurrences of a nonce (which can matter if associations are in use and there is no check_authentication phase). Relying party may also choose to reject a nonce on the basis of the timestamp being out of an acceptable range.
Available options include:
nocheck (boolean) Skip response_nonce checking entirely. This overrides all other nonce_options. lifetime (integer) Cache entries for nonces will expire after this many seconds.
Defaults to the value of window, below.
If lifetime is zero or negative, expiration times will not be set at all; entries will expire as per the default behavior for your cache (or you will need to purge them via some separate process).
ignoretime (boolean) Do not do any checking of timestamps, i.e., only test whether nonce is in the cache. This overrides all other nonce options except for lifetime and nocheck skew (integer) Number of seconds that a provider clock can be ahead of ours before we deem it to be misconfigured.
Default skew is 300 (5 minutes) or window/2, if window is specified and window/2 is smaller.
(skew is treated as 0 if set negative, but dont do that).
Misconfiguration of the provider clock means its timestamps are not reliable, which then means there is no way to know whether or not the nonce could have been sent before the start of the cache window, which nullifies any obligation to detect all multiply sent nonces. Conversely, if proper configuration can be assumed, then the timestamp value minus skew will be the earliest possible time that we could have received a previous instance of this response_nonce, and if the cache is reliable about holding entries from that time forward, then (and only then) can one be certain that an uncached nonce instance is indeed the first.
start (integer) Reject nonces where timestamp minus skew is earlier than start (absolute seconds; default is zero a.k.a. midnight 1/1/1970 UTC)
If you know the start time of your HTTP server (or your cache server, if that is separate X or the maximum of the start times if you have multiple cache servers), you should use this option to declare that.
window (integer) Reject nonces where timestamp minus skew is more than window seconds ago. Zero or negative values of window are treated as infinite (i.e., allow everything).
If lifetime is specified, window defaults to that. If lifetime is not specified, window defaults to 1800 (30 minutes), adjusted upwards if skew is specified and larger than the default skew.
On general principles, window should be a maximal expected propagation delay plus twice the skew.
Values between 0 and skew (causing all nonces to be rejected) and values greater than lifetime (cache may fail to keep all nonces that are still within the window) are not recommended.
timecop (boolean) Reject nonces from The Future (i.e., timestamped more than skew seconds from now).
Note that rejecting future nonces is not required. Nor does it protect from anything since an attacker can retry the message once it has expired from the cache but is still within the time interval where we would not yet expect that it could expire X this being the essential problem with future nonces. It may, however, be useful to have warnings about misconfigured provider clocks X and hence about this insecurity X at the cost of impairing interoperability (since this rejects messages that are otherwise allowed by the protocol), hence this option.
In most cases it will be enough to either set nocheck to dispense with response_nonce checking entirely because some other (better) method of preventing replay attacks (see <B>consumer_secretB>) has been implemented, or use lifetime to declare/set the lifetime of cache entries for nonces whether because the default lifetime is unsatisfactory or because the cache implementation is incapable of setting individual expiration times. All other options should default reasonably in these cases.
In order for the nonce check to be as reliable/secure as possible (i.e., that it block all instances of duplicate nonces from properly configured providers as defined by skew, which is the best we can do), start must be no earlier than the cache start time and the cache must be guaranteed to hold nonce entries for at least window seconds (though, to be sure, if you can tolerate being vulnerable for the first window seconds of a server run, then you do not need to set start).
$csr-><B>claimed_identityB>($url) Given a user-entered $url (which could be missing http://, or have extra whitespace, etc), converts it to canonical form, performs partial discovery to confirm that at least one provider endpoint exists, and returns a Net::OpenID::ClaimedIdentity object, or, on failure of any of the above, returns undef and sets last error ($csr-><B>errB>).
Note that the identity returned is not verified yet. Its only who the user claims they are, but they could be lying.
If this method returns undef, an error code will be set. See Error Codes below.
The following routines are for handling a redirected provider response and assume that, among other things, $csr-><B>argsB> has been properly populated with the URL parameters.
$csr-><B>handle_server_responseB>( %callbacks ); When a request comes in that contains a response from an OpenID provider, figure out what it means and dispatch to an appropriate callback to handle the request. This is the callback-based alternative to explicitly calling the methods below in the correct sequence, and is recommended unless you need to do something strange.
Anything you return from the selected callback function will be returned by this method verbatim. This is useful if the caller needs to return something different in each case.
The available callbacks are:
not_openid the request isnt an OpenID response after all. setup_needed a checkid_immediate mode request was rejected, indicating that the provider requires user interaction. cancelled the user cancelled the authentication request from the providers UI. verified ($verified_identity) the users identity has been successfully verified. A Net::OpenID::VerifiedIdentity object is passed in. error ($errcode, $errmsg) an error has occurred. An error code and message are provided. See Error Codes below for the meanings of the codes.
For the sake of legacy code we also allow
setup_required ($setup_url) <B>[DEPRECATED]B> a checkid_immediate mode request was rejected and $setup_url was provided. $csr-><B>is_server_responseB> Returns true if a set of URL parameters has been supplied (via $csr-><B>argsB>) and constitutes an actual OpenID protocol message. $csr-><B>setup_neededB> Returns true if a checkid_immediate request failed because the provider requires user interaction. The correct action to take at this point depends on the OpenID protocol version
(Version 1) Redirect to or otherwise make available a link to $csr->user_setup_url.
(Version 2) Retry the request in checkid_setup mode; the provider will then issue redirects as needed.
<B>N.B.B>: While some providers have been known to supply the user_setup_url parameter in Version 2 setup_needed responses, you cannot rely on this, and, moreover, since the OpenID 2.0 specification has nothing to say about the meaning of such a parameter, you cannot rely on it meaning anything in particular even if it is supplied. $csr-><B>user_setup_urlB>( [ %opts ] ) (Version 1 only) Returns the URL the user must return to in order to login, setup trust, or do whatever the identity provider needs them to do in order to make the identity assertion which they previously initiated by entering their claimed identity URL.
<B>N.B.B>: Checking whether user_setup_url is set in order to determine whether a checkid_immediate request failed is DEPRECATED and will fail under OpenID 2.0. Use setup_needed() instead.
The base URL that this function returns can be modified by using the following options in %opts:
Its then your job to restore your app to where it was prior to redirecting them off to the user_setup_url, using the other query parameters that youd sent along in your return_to URL.
$csr-><B>verified_identityB>( [ %opts ] ) Returns a Net::OpenID::VerifiedIdentity object, or returns undef and sets last error ($csr-><B>errB>). Verification includes double-checking the reported identity URL declares the identity provider, verifying the signature, etc.
The options in %opts may contain:
required_root Sets the required_root just for this request. Values returns to its previous value afterwards.
If this method returns undef, an error code will be set. See Error Codes below.
This is the complete list of error codes that can be set. Errors marked with (C) are set by <B>claimed_identityB>. Other errors occur during handling of provider responses and can be set by <B>argsB> (A), <B>verified_identityB> (V), and <B>user_setup_urlB> (S), all of which can show up in the error callback for <B>handle_server_responseB>.
provider_error (A) The protocol message is a (2.0) error mode (i.e., openid.mode = error) message, typically used for provider-specific error responses. Use $csr-><B>messageB> to get at the contact and reference fields. empty_url (C) Tried to do discovery on an empty or all-whitespace string. bogus_url (C) Tried to do discovery on a non-http:/https: URL. protocol_version_incorrect (C) None of the ID providers found support even the minimum protocol version ($csr-><B>minimum_versionB>) no_identity_server (CV) Tried to do discovery on a URL that does not seem to have any providers at all. bad_mode (SV) The openid.mode was expected to be id_res (positive assertion or, in version 1, checkid_immediate failed). no_identity (V) The openid.identity parameter is missing. no_sig (V) The openid.sig parameter is missing. no_return_to (V) The openid.return_to parameter is missing bogus_return_to (V) The return_to URL does not match $csr-><B>required_rootB> nonce_missing (V) The openid.response_nonce parameter is missing. nonce_reused (V) A previous assertion from this provider used this response_nonce already. Someone may be attempting a replay attack. nonce_format (V) Either the response_nonce timestamp was not in the correct format (e.g., tried to have fractional seconds or not UTC) or one of the components was out of range (e.g., month = 13). nonce_future (V) timecop was set and we got a response_nonce that was more than skew seconds into the future. nonce_stale (V) We got a response_nonce that was either prior to the start time or more than window seconds ago. time_expired (V) The return_to signature time (oic.time) is from too long ago. time_in_future (V) The return_to signature time (oic.time) is too far into the future. time_bad_sig (V) The HMAC of the return_to signature (oic.time) is not what it should be. server_not_allowed (V) None of the provider endpoints found for the given ID match the server specified by the openid.op_endpoint parameter (OpenID 2 only). unexpected_url_redirect (V) Discovery for the given ID ended up at the wrong place bogus_delegation (V) Asserted identity (openid.identity) does not match claimed_id or local_id/delegate. unsigned_field (V) In OpenID 2.0, openid.op_endpoint, openid.return_to, openid.response_nonce, and openid.assoc_handle must always be signed, while openid.claimed_id and openid.identity must be signed if present. expired_association (V) openid.assoc_handle is for an association that has expired. signature_mismatch (V) An attempt to confirm the positive assertion using the association given by openid.assoc_handle failed; the signature is not what it should be. naive_verify_failed_network (V) An attempt to confirm the positive assertion via direct contact (check_authentication) with the provider failed with no response or a bad status code (!= 200). naive_verify_failed_return (V) An attempt to confirm a positive assertion via direct contact (check_authentication) received an explicitly negative response (openid.is_valid = FALSE).
XRI-based identities are not supported.
Meanwhile, here are answers to the security profile questions from section 15.6 of the OpenID 2.0 specification <http://openid.net/specs/openid-authentication-2_0.html#anchor47> that are relevant to the Consumer/Relying-Party:
1. Are wildcards allowed in realms? <B>Yes.B> 2. N/A. 3. Types of claimed identifiers accepted. <B>HTTP or HTTPSB> 4. Are self-issued certificates allowed for authentication? <B>Depends entirely on the user agent (B>ua<B>) supplied. LWP::UserAgent, as of version 6.0, can be configured to only accept connections to sites with certificates deriving from a set of trusted roots.B> 5. Must the XRDS file be signed? <B>No.B> 6. Must the XRDS file be retrieved over secure channel? <B>No.B> 7. What types of session types can be used when creating associations? <B>Any of B>no-encryption<B>,B>DH-SHA1<B>,B>DH-SHA256<B>B> 8. N/A. 9. N/A. 10. Must the association request take place over a secure channel? <B>If the session type is B>no-encryption<B>, then Yes for version 2.0 providers and likewise for version 1.1 providers if B>allow_eavesdropping<B> is not set, otherwise No.B>
This module is Copyright (c) 2005 Brad Fitzpatrick. All rights reserved.
You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file. If you need more liberal licensing terms, please contact the maintainer.
This is free software. IT COMES WITHOUT WARRANTY OF ANY KIND.
The Net::OpenID family of modules has a mailing list powered by Google Groups. For more information, see <http://groups.google.com/group/openid-perl>.
OpenID website: <http://openid.net/>
Net::OpenID::ClaimedIdentity part of this module
Net::OpenID::VerifiedIdentity part of this module
Net::OpenID::Server another module, for implementing an OpenID identity provider/server
Brad Fitzpatrick <firstname.lastname@example.org>
Tatsuhiko Miyagawa <email@example.com>
Martin Atkins <firstname.lastname@example.org>
Robert Norris <email@example.com>
Roger Crew <firstname.lastname@example.org>
|perl v5.20.3||NET::OPENID::CONSUMER (3)||2016-02-08|