[Directory Wiki] Update of "SpnegoCodec" by EmmanuelLecharny

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by EmmanuelLecharny:
http://wiki.apache.org/directory/SpnegoCodec

The comment on the change is:
Created this page from the ASN.1 page

New page:
= SPNEGO ASN.1 codec =
[[TableOfContents]]

== Spnego ASN.1 State Automaton ==
The SPNEGO ASN.1 grammar seems very simple, but as there are a lot of optional elements, it is not that simple to implement...

It is fully described in RFC 2478.

=== Spnego Grammar ===
Here is the SPNEGO grammar :

{{{

NegotiationToken ::= CHOICE {
    negTokenInit  [0]  NegTokenInit,
    negTokenTarg  [1]  NegTokenTarg 
}

NegTokenInit ::= SEQUENCE {
    mechTypes       [0] MechTypeList  OPTIONAL,
    reqFlags        [1] ContextFlags  OPTIONAL,
    mechToken       [2] OCTET STRING  OPTIONAL,
    mechListMIC     [3] OCTET STRING  OPTIONAL
}

NegTokenTarg ::= SEQUENCE {
    negResult      [0] ENUMERATED {
                            accept_completed    (0),
                            accept_incomplete   (1),
                            reject              (2) }          OPTIONAL,
    supportedMech  [1] MechType                                OPTIONAL,
    responseToken  [2] OCTET STRING                            OPTIONAL,
    mechListMIC    [3] OCTET STRING                            OPTIONAL
}

MechTypeList ::= SEQUENCE OF MechType

MechType::= OBJECT IDENTIFIER

ContextFlags ::= BIT STRING {
        delegFlag       (0),
        mutualFlag      (1),
        replayFlag      (2),
        sequenceFlag    (3),
        anonFlag        (4),
        confFlag        (5),
        integFlag       (6)
}

}}}

=== Spnego state automaton ===

Here is the state automaton of this grammar :

attachment:spnego.png

We can see that the automaton is quite intricated. The following picture is a typical PDU of the first part of this grammar : the '''Neg``Token``Init''' element :

attachment:spnego-pdu.png

Of course, as some elements are optional, this PDU could be very different. Here is another PDU, where the '''req``Flags''' and the '''mech``List``MIC''' are missing :

attachment:spnego-pdu2.png

=== Spnego used POJO's ===

We will store the result of a decoding in POJO's, where each constructed element is implemented as a POJO.

==== Spnego Neg Token INIT POJO ====

Here is the class diagram that could be used to store a SPNEGO '''neg``Token``Init''' :

attachment:spnego-class-diag1.png

This is a little bit complicated, and some classes could be implemented as members. We just have to aggregate the '''Length''' part of each POJO as members in the main POJO, to be able to check the length while processing the decoding.

Here is the definitive class diagram :

attachment:spnego-class-diag2.png

==== Spnego Neg Token Targ POJO ====

This POJO is a little simpler, as there is no recursive element. 

The following schema shows a PDU where we can see the Length dependencies.

attachment:spnego-neg-token-targ-PDU.png

As we can see, we will have to keep a track of the expected length of following parts :

 * The negTokenArg length must be equal to the length of the negTokenTargSequence TLV
 * The negTokenTargSequence length must be equal to the sum of each included TLV
 * and so on...