eZ Components - Authentication ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. contents:: Table of Contents Introduction ============ Description ----------- The purpose of the Authentication component is to provide support for different means of identification and authentication of users using different providers and protocols. Class overview ============== An overview of the most important classes in the Authentication component. Base classes ------------ ezcAuthentication Main class of Authentication. It is a container for authentication filters, which will be run in sequence. The method run() returns true or false depending on the success of the authentication filters. ezcAuthenticationCredentials Structure which holds user credentials. Types are id credentials (ezcAuthenticationIdCredentials) and id + password credentials (ezcAuthenticationPasswordCredentials). Usually there is only one credentials object in the application. Multiple credentials can be used via the ezcAuthenticationGroupFilter class. ezcAuthenticationSession Used to store the authenticated username and the timestamp between requests. Authentication filters ---------------------- ezcAuthenticationDatabaseFilter Filter to authenticate against a database. Uses a database instance provided by the Database component (via the ezcDbInstance::get() function). It depends on the Database component, so it is implemented in the the tie-in component `AuthenticationDatabaseTiein`_. ezcAuthenticationGroupFilter Container filter for 2 or more filters. Depending on configuration, at least one filter needs to succeed in order for the group to succeed, or all filters need to succeed in order for the group to succeed. ezcAuthenticationHtpasswdFilter Filter to authenticate against a htpasswd password file. Supports the same encryption methods as the Unix command htpasswd, and the encryption method is detected automatically from the file. ezcAuthenticationLdapFilter Filter to authenticate against an LDAP directory. For now the password can be only in plain text. It depends on the PHP ldap extension. ezcAuthenticationOpenidFilter Filter to authenticate against OpenID. For now the OpenID versions 1.0 and 1.1 are supported. ezcAuthenticationTokenFilter Filter used to implement CAPTCHA tests. It basically compares the server generated token with the value entered by the user, using a specified hashing callback function. Stores ------ OpenID uses a store to hold the generated nonces and the associations (in "smart" mode). If there is no store specified, then nonces are not checked. ezcAuthenticationOpenidStore Abstract class from which the different stores inherit. ezcAuthenticationOpenidFileStore Uses file storage. Nonces are stored in files named after the nonce itself, and associations are stored in files named after the OpenID provider with which the association is made. ezcAuthenticationOpenidDbStore Database storage. Nonces and associations are stored in two tables, with names defined as options in ezcAuthenticationOpenidDbStoreOptions. Implemented in `AuthenticationDatabaseTiein`_. General authentication ====================== Stateless authentication ------------------------ The general template for authentication is: - get the user credentials (eg. in a ezcAuthenticationPasswordCredentials object) - create an object of class ezcAuthentication and pass the credentials object to it - add authentication filters to the authentication object with addFilter() - call the run() method of the authentication object - call the getStatus() method of the authentication object and analyse it The following example demonstrates the above steps. .. include:: tutorial/tutorial_authentication.php :literal: First, a credentials object is created with username jan.modaal and password 'b1b3773a05c0ed0176787a4f1574ff0075f7521e' (sha1() hash). An authentication object is created using the credentials object, and a htpasswd filter (using the /etc/htpasswd file) is added to it. After running the authentication (line 8), if the username and the password do not pass through the htpasswd filter, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect", "Password incorrect"). If run() returned true (line 24) then the user is logged-in and he can see his content. Using session ------------- The following example shows how to use the session class to store authentication information (username and timestamp) between requests. .. include:: tutorial/tutorial_session.php :literal: A session class is created and used to start the PHP session. The username and password (provided by the user through a POST form) are fetched and used to create a credentials object. An authentication object is created using the credentials object, and the session class is added to the authentication object. In addition an htpasswd filter (using the /etc/htpasswd file) is added to the authentication object. After running the authentication (line 14), if the username and the password do not pass through the session class or the htpasswd filter, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect", "Password incorrect", "Session expired"). If run() returned true (line 34) then the user is logged-in and he can see his content. Improving authentication performance when using the session ``````````````````````````````````````````````````````````` When using the session, it is often desirable to take advantage of the fact that the authenticated state of the user is kept in the session and not create and initialize the other filters (which might slow things down on every request). The application can be structured like this: :: start(); $credentials = new ezcAuthenticationPasswordCredentials( $user, $pass ); $authenticated = false; if ( !$session->isValid( $credentials ) ) { // create the authentication object $authentication = new ezcAuthentication( $credentials ); $authentication->session = $session; // create filters and add them to the authentication object $authentication->addFilter( new ezcAuthenticationOpenidFilter() ); // run the authentication object if ( !$authentication->run() ) { $status = $authentication->getStatus(); // build an error message based on $status } else { $authenticated = true; } } else { $authenticated = true; } if ( $authenticated ) { // the authentication succeeded and the user can see his content } else { // inform the user that the authentication failed (with the error // message that was created earlier) } ?> In this way, the creation and initialization of the authentication filters is not performed if the credentials are stored in the session. Authentication filters ====================== Database -------- See the `AuthenticationDatabaseTiein`_ component. Group ----- The following example shows how to use a group filter to authenticate against EITHER a database or an LDAP directory. .. include:: tutorial/tutorial_group.php :literal: First, a credentials object is created with username 'jan.modaal' and password 'qwerty'. An authentication object is created using the credentials object. A group filter is added to it, consisting of a Database filter and an LDAP filter. After running the authentication (line 19), if the username and the password do not pass through any of the filters in the group, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect", "Password incorrect"). If run() returned true (line 39) then the user is logged-in and he can see his content. Multiple credentials ```````````````````` To be able to use multiple credentials for authentication (each filter with its own credentials), you must enable the multipleCredentials option for ezcAuthenticationGroupFilter. The following example demonstrates how to use multiple credentials. .. include:: tutorial/tutorial_multiple_credentials.php :literal: First, two credentials objects are created. A Group filter is created with the multipleCredentials option enabled. Two Htpasswd filters are added to the Group filter, each with their own credentials. An Authentication object is created with a default credentials (which would have been used for other filters outside the Group filter, and to save the authenticated state in the session). The Group filter is then added to the Authentication object. After running the authentication (line 19), if the usernames and the passwords do not pass through the htpasswd filters, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect john.doe", "Password incorrect for john.doe", etc). If run() returned true (line 44) then the user is logged-in and he can see his content. The above example will output: :: Incorrect password for jan.modaal Htpasswd -------- The following example shows how to authenticate against an htpasswd file. .. include:: tutorial/tutorial_htpasswd.php :literal: First, a credentials object is created with username jan.modaal and password 'b1b3773a05c0ed0176787a4f1574ff0075f7521e' (sha1() hash). An authentication object is created using the credentials object, and a htpasswd filter (using the /etc/htpasswd file) is added to it. After running the authentication (line 9), if the username and the password do not pass through the htpasswd filter, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect", "Password incorrect"). If run() returned true (line 25) then the user is logged-in and he can see his content. LDAP ---- The following example shows how to authenticate agains an LDAP directory. .. include:: tutorial/tutorial_ldap.php :literal: First, a credentials object is created with username jan.modaal and password 'qwerty'. An authentication object is created using the credentials object, and an LDAP filter is added to it. The $ldap structure specifies the LDAP host (localhost), the format of the directory entry (%id% is a placeholder which will be replaced by the actual value at bind time), the base of the directory entry ('dc=example,dc=com') and the port on which to connect to the host (389). After running the authentication (line 7), if the username and the password do not pass through the LDAP filter, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Username incorrect", "Password incorrect"). If run() returned true (line 34) then the user is logged-in and he can see his content. Fetch extra data during LDAP authentication ``````````````````````````````````````````` Any data that is defined for an acount can be fetched. Before running the authentication process (before calling run(), register which data needs to be fetched. Example: :: // $filter is an ezcAuthenticationLdapFilter object $filter->registerFetchData( array( 'name', 'company', 'mobile' ) ); After the authentication process is finished (after run()), retrieve the data that was registered: :: // $filter is an ezcAuthenticationLdapFilter object $data = $filter->fetchData(); For the previous example, the $data array will be something like this: :: array( 'name' => array( 'Dr. No' ), 'company' => array( 'SPECTRE' ), 'mobile' => array( '555-7732873' ) ); OpenID ------ OpenID has 2 modes of operation: *dumb* and *smart*. These modes define the way the consumer (the application server, on which the Components run) is communicating with the OpenID provider (another server where users authenticate with their OpenID username and password; there are many of these and users can register on which one they want). *Dumb mode* (stateless) In this mode there are 3 http requests: Discovery The consumer requests the URL which the user entered and finds out the URL of the provider. openid.checkid_setup The consumer redirects the browser to the provider, so that the user can enter his username and password to the provider. The provider then redirects back to the consumer. The URL to which the provider redirects back can be configured with the OpenID option redirectUrl (see ezcAuthenticationOpenidOptions). The checkid_immediate mode is supported as well, for authentication in a pop-up window or iframe (or similar techniques). See below the section `OpenID immediate mode`_ for details. openid.check_authentication The consumer sends to the provider the values received in step 2 and receives the information if the user is authenticated or not. *Smart mode* (keeping state) In this mode there are also 3 http requests, but only 2 every time and 1 request from time to time: Discovery Same as in dumb mode. openid.checkid_setup Same as in dumb mode, but the handle associated with the shared secret is sent as well. The extra request (which is done from time to time) is: openid.associate The consumer and the provider establish a shared secret, which the consumer uses when it redirects in step 2, and it will use the same secret for all requests to the same provider. Step 3 (openid.check_authentication) is not required anymore. The shared secret has a timeout period, so it must be renewed from time to time. OpenID "dumb" (stateless) mode `````````````````````````````` The following example shows how to authenticate against OpenID in "dumb" (stateless) mode. .. include:: tutorial/tutorial_openid_dumb.php :literal: A session class is created and used to start the PHP session. The OpenID identifier (provided by the user through a GET form) is fetched and used to create a credentials object. On subsequent requests to the page, the token is loaded from session instead of the GET form. OpenID specifications recommend the name 'openid_identifier' for the text field of the form in which users type their OpenID identifier (so that browser can prefill the field if user chooses this). An authentication object is created using the credentials object, and the session handler is added to it. If the user is at logout (line 15), then the session is destroyed, which means the user will see the login form. If the user is not at logout (line 19), then an OpenID filter is created with the credentials object. After running the authentication (line 25), if the OpenID server did not authorize the identifier, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Signature incorrect", "Session expired"). At line 46 a simple HTML form is displayed, as example. The form displays the OpenID logo (as suggested by the OpenID specifications). If run() returned true (line 55) then the user is logged-in and he can see his content. Line 59 contains an example of how to implement a logout option for the application. OpenID "smart" (stateful) mode `````````````````````````````` The following example shows how to authenticate against OpenID in "smart" (stateful) mode. .. include:: tutorial/tutorial_openid_smart.php :literal: The only differences between this example and the one in the previous section is defining the mode of the OpenID filter, and defining a store (file store in this example or database store as shown in the OpenID example in `AuthenticationDatabaseTiein`_) which will hold the associations. In addition the store will also hold the nonces which are used to prevent replay attacks. OpenID immediate mode ````````````````````` The OpenID request checkid_immediate is supported, which allows for user authentication in a pop-up window or iframe (or similar techniques). Instead of redirecting the user agent as in the checkid_setup step, the developer has the possibility to open a pop-up/iframe for the user to authenticate with the OpenID provider. A more detailed description of the process: when using checkid_immediate, the OpenID provider is asked if the user can be authenticated on the spot, with no redirection of the user agent. If the user cannot be authenticated, the provider sends back a setup URL, which the application can use in a pop-up window or iframe to display to the user so that he can authenticate himself to the OpenID provider. After user enters his OpenID username and password at this page and accepts the originating site, the pop-up window or iframe is redirected to the return URL value (which should be a different page than the page which opens the pop-up window). The return URL page will then inform the main page of success or failure through JavaScript, and the main page can do the action that it needs to perform based on the outcome in the pop-up page. The checkid_immediate mode is enabled by setting the option immediate to true. Note: retrieval of extra data during authentication (fullname, email, etc) is not possible at the moment when using the immediate mode. For example, this is one simple way of implementing checkid_immediate: - the main page contains the OpenID login form (where the user types in his OpenID identifier). This page contains also a hidded form value which specifies to which page to return to in the pop-up window. The Enter key and the submit button should be disabled on the form. When user clicks on the Login button, the main page should employ AJAX to request the return URL. When the return URL finishes loading, the main page will read from the return URL page the setup URL and it will open it in a pop-up/iframe. - the return URL page enables the option immediate to the OpenID filter, and runs the filter. It gets back the setup URL and it echoes it to be picked-up by the main page once the return URL page will finish loading. The setup URL should be the only thing that the return URL page is echoing, to not interfere with the main page. - in the pop-up/iframe the setup URL will load, which basically depends on the OpenID provider how it is handled by the user. After the user enters his credentials on the setup URL page, he will be redirected to the return URL, which should detect this, and which should inform the main page that the user was authenticated to the OpenID provider. A rudimentary source code example is provided below. It does not contain code to inform the user that the session expired or the errors experienced during the authentication process. The code has been tested on some browsers (Firefox 1.5, Konqueror 3.5, Internet Explorer 6.0), but it is possible that some browsers might have issues with the JavaScript code. The main page: .. include:: tutorial/tutorial_openid_ajax.php :literal: This page handles the session, and contains JavaScript code to read from the return URL page the setup URL, and to open a pop-up page with that setup URL. The pop-up page (also return URL): .. include:: tutorial/tutorial_openid_immediate.php :literal: This page also contains code to handle the session, in addition to handling the OpenID authentication. It will be called 2 times: - first by the main page, with the immediate=true query parameter. A connection to the OpenID provider is created, and a setup URL is fetched, which will be echoed to be picked up by the main page. The main page then opens the setup URL in a pop-up window. - second, by the setup URL, as the openid.return_to query parameter is set to redirect back to this page. The OpenID filter is called again, this time to check the signature in the return URL, and if it authenticates successfully, the main page is informed of this (line 80) and the pop-up window is closed. Other methods can be employed to inform the main page, and the main page can do other actions instead of just displaying a message. Fetch extra data during OpenID authentication ````````````````````````````````````````````` Any data that is defined for an acount can be fetched. Before running the authentication process (before calling run(), register which data needs to be fetched. Example: :: // $filter is an ezcAuthenticationOpenidFilter object $filter->registerFetchData( array( 'fullname', 'gender', 'country', 'language' ) ); After the authentication process is finished (after run()), retrieve the data that was registered: :: // $filter is an ezcAuthenticationOpenidFilter object $data = $filter->fetchData(); For the previous example, the $data array will be something like this: :: array( 'fullname' => array( 'John Doe' ), 'gender' => array( 'M' ), 'country' => array( 'US' ), 'language' => array( 'FR' ) ); Note: when using the immediate OpenID mode (by setting the option immediate to true), extra data cannot be fetched during authentication. Token ----- The following example shows how to create a CAPTCHA test. The example is divided into 2 parts: the initial request (where the user sees the CAPTCHA image and enters the characters he sees in a form) and the follow-up request (after the user submits the form). On the initial request: .. include:: tutorial/tutorial_token1.php :literal: A 6 characters random token is created and encrypted using sha1(). The token is saved in the session to be available in the follow-up request. An image must be generated from the unencrypted token to be displayed to the user. On the follow-up request: .. include:: tutorial/tutorial_token2.php :literal: The token generated on the initial request is fetched from the session, and the CAPTCHA value entered by the user is fetched from the POST request. A credentials object is created from the CAPTCHA value, and it is used to create an authentication object. A Token filter is created from the stored encrypted token value, and it is added to the authentication object. The second argument of the Token constructor indicates that the CAPTCHA value will be hashed with sha1() before comparing it with the token value. After calling run() on the authentication object (line 14), if the token and CAPTCHA values don't match, then the CAPTCHA test was incorrect. The developer decides how to handle this situation (user tries again, user is banned, etc). If the values match (line 19) then it means the user passed the CAPTCHA test (or the bots managed to OCR the image). TypeKey ------- The following example shows how to authenticate against TypeKey. .. include:: tutorial/tutorial_typekey.php :literal: A session class is created and used to start the PHP session. The TypeKey token (provided by the user through a GET form) is fetched and used to create a credentials object. On subsequent requests to the page, the token is loaded from session instead of the GET form. An authentication object is created using the credentials object, and a TypeKey filter is added to it, along with the session class. After running the authentication (line 19), if the TypeKey server did not authorize the token, then the credentials are incorrect and the user must be informed. The getStatus() method is used for this. The values in the status returned must be cycled through and for each value a response is created for the user ("Signature incorrect", "Session expired"). At line 39 an HTML form is displayed, as example on how to attach the TypeKey token to the _return hidded field which will be sent to the TypeKey server. If run() returned true (line 46) then the user is logged-in and he can see his content. Fetch extra data during TypeKey authentication `````````````````````````````````````````````` The extra data that can be fetched is name (the TypeKey username), nick (the TypeKey display name) and email (the user email address). The email address can only be fetched if need_email was included in the initial request to the TypeKey server with a value other than 0, and if the user allowed the sharing of his email address. Example: :: https://www.typekey.com/t/typekey/login?t=&_return=&need_email=1 After the authentication process is finished (after run()), retrieve the extra data: :: // $filter is an ezcAuthenticationTypekeyFilter object $data = $filter->fetchData(); The $data array will be something like this: :: array( 'name' => array( 'john' ), 'nick' => array( 'John Doe' ), 'email' => array( 'john.doe@example.com' ) // or not set ); Securing applications ===================== `Securing applications`_ - A guide to improve the security of online applications. It is not exhaustive, but it provides solutions against common attacks. .. _Securing applications: Authentication_security.html .. _AuthenticationDatabaseTiein: introduction_AuthenticationDatabaseTiein.html .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79 nocin