AA Protocol Examples

Server Reply

Access Authorization package in server-side may react in four different ways to a request:

401 Unauthorized, when:
- no authorization information given
- wrong authentication scheme
- authentication failed
- not authorized to access document
403 Forbidden
- request is forbidden, and authorization won't help
404 Not found
- requested file doesn't exist; to get this message the user has to have first authenticated himself successfully and be otherwise authorized to access that file (if it existed)
200 Document follows
- document may be encrypted, depending on protection scheme; this can be determined by looking at the first header lines

In the first and last case there are special reply header lines giving additional information.

"Unauthorized" Server Reply

    HTTP/1.0 401 Unauthorized
    WWW-Authenticate: Basic realm="blaa.blaa"
    WWW-Authenticate: Pubkey realm="blaa.blaa", key="LQEWRsdfFDjf23SsDf2i1hjT="
    ...

Server replies that the document is protected, and it is willing to accept authentication done according to Basic or Pubkey authentication scheme.

realm in Basic scheme is used to inform the browser about servers that use the same password file (these servers use the same realm name; this should be the main password server's full machine name).

If Kerberos or such is accepted, there is a header line containing something like this:

    WWW-Authenticate: KerberosV4 realm="bsdi.com", principle="foo"

This can be specified in further detail by the person putting Kerberos in.

"OK" Server Reply

If there is no encryption used, the reply from server after access authorization is identical with what it would be without access authorization. However, if encryption is used, the reply is as follows:

        HTTP/1.0 200 Document follows
        DEK-Info: DES-CBC,BFF968AA74691AC1
        Key-Info: DES_ECB,DJSFo7dSDFf34hKHFD8234jDFf2bfasdf832DF3nZ
	MIC-Info: MD5,
         LDKJF3kr34hfDuf23r98FBk38ftDFP9873hbrFDp9gb23kfDPF2b3JfKeL7G
         DLkwtDICl234FJi9834kjfslk
	... other headers and the encrypted document follow ...

DEK-Info:, Key-Info: and MIC-Info: fields are almost as in RFC1421.

If Kerberos or such is used, there is also a header line authenticating the server:

        WWW-Authentication: KerberosV4 <kerberos-stuff>

This is otherwise like Authorization:, but it goes to the other direction, and there is no sence in naming it Authorization: because server authorization-checks on client-side make no sence. This is to be specified in more detail by other instances.

Browser Request

When a browser gets an Unauthorized status code or otherwise figures authorization is needed, it sends authorization information along with the next request to the server.

Basic Authentication Scheme

        GET whatever HTRQ/V1.0
        Authorization: Basic KDENfKdifwekFD23nf==
	...

The string after Basic is username:password encoded into printable characters per RFC1421.

Pubkey Authentication Scheme

        GET whatever HTRQ/V1.0
        Authorization: Pubkey GeHKWeaDrtErtyNhXfdGhKdgHDfghIfWekFD23nGDfg4gfX=
	...

The string after Pubkey is username:password:browser_inet_address:timestamp:browser_key encrypted by server's public key and encoded into printable characters.

Kerberos Authentication Scheme

        GET whatever HTRQ/V1.0
        Authorization: KerberosV4 <kerberos-ticket>
	...

This is to be specified in more detail by other instances.

AL 12 December 1993