Abhilash S.L | 3b49463 | 2019-07-16 15:51:09 +0530 | [diff] [blame] | 1 | package types |
| 2 | |
| 3 | import ( |
| 4 | "github.com/jcmturner/gofork/encoding/asn1" |
| 5 | ) |
| 6 | |
| 7 | // Reference: https://www.ietf.org/rfc/rfc4120.txt |
| 8 | // Section: 5.2.6 |
| 9 | |
| 10 | /* |
| 11 | AuthorizationData |
| 12 | |
| 13 | -- NOTE: AuthorizationData is always used as an OPTIONAL field and |
| 14 | -- should not be empty. |
| 15 | AuthorizationData ::= SEQUENCE OF SEQUENCE { |
| 16 | ad-type [0] Int32, |
| 17 | ad-data [1] OCTET STRING |
| 18 | } |
| 19 | |
| 20 | ad-data |
| 21 | This field contains authorization data to be interpreted according |
| 22 | to the value of the corresponding ad-type field. |
| 23 | |
| 24 | ad-type |
| 25 | This field specifies the format for the ad-data subfield. All |
| 26 | negative values are reserved for local use. Non-negative values |
| 27 | are reserved for registered use. |
| 28 | |
| 29 | Each sequence of type and data is referred to as an authorization |
| 30 | element. Elements MAY be application specific; however, there is a |
| 31 | common set of recursive elements that should be understood by all |
| 32 | implementations. These elements contain other elements embedded |
| 33 | within them, and the interpretation of the encapsulating element |
| 34 | determines which of the embedded elements must be interpreted, and |
| 35 | which may be ignored. |
| 36 | |
| 37 | These common authorization data elements are recursively defined, |
| 38 | meaning that the ad-data for these types will itself contain a |
| 39 | sequence of authorization data whose interpretation is affected by |
| 40 | the encapsulating element. Depending on the meaning of the |
| 41 | encapsulating element, the encapsulated elements may be ignored, |
| 42 | might be interpreted as issued directly by the KDC, or might be |
| 43 | stored in a separate plaintext part of the ticket. The types of the |
| 44 | encapsulating elements are specified as part of the Kerberos |
| 45 | specification because the behavior based on these values should be |
| 46 | understood across implementations, whereas other elements need only |
| 47 | be understood by the applications that they affect. |
| 48 | |
| 49 | Authorization data elements are considered critical if present in a |
| 50 | ticket or authenticator. If an unknown authorization data element |
| 51 | type is received by a server either in an AP-REQ or in a ticket |
| 52 | contained in an AP-REQ, then, unless it is encapsulated in a known |
| 53 | authorization data element amending the criticality of the elements |
| 54 | it contains, authentication MUST fail. Authorization data is |
| 55 | intended to restrict the use of a ticket. If the service cannot |
| 56 | determine whether the restriction applies to that service, then a |
| 57 | security weakness may result if the ticket can be used for that |
| 58 | service. Authorization elements that are optional can be enclosed in |
| 59 | an AD-IF-RELEVANT element. |
| 60 | |
| 61 | In the definitions that follow, the value of the ad-type for the |
| 62 | element will be specified as the least significant part of the |
| 63 | subsection number, and the value of the ad-data will be as shown in |
| 64 | the ASN.1 structure that follows the subsection heading. |
| 65 | |
| 66 | Contents of ad-data ad-type |
| 67 | |
| 68 | DER encoding of AD-IF-RELEVANT 1 |
| 69 | |
| 70 | DER encoding of AD-KDCIssued 4 |
| 71 | |
| 72 | DER encoding of AD-AND-OR 5 |
| 73 | |
| 74 | DER encoding of AD-MANDATORY-FOR-KDC 8 |
| 75 | |
| 76 | */ |
| 77 | |
| 78 | // AuthorizationData implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6 |
| 79 | type AuthorizationData []AuthorizationDataEntry |
| 80 | |
| 81 | // AuthorizationDataEntry implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6 |
| 82 | type AuthorizationDataEntry struct { |
| 83 | ADType int32 `asn1:"explicit,tag:0"` |
| 84 | ADData []byte `asn1:"explicit,tag:1"` |
| 85 | } |
| 86 | |
| 87 | // ADIfRelevant implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.1 |
| 88 | type ADIfRelevant AuthorizationData |
| 89 | |
| 90 | // ADKDCIssued implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.2 |
| 91 | type ADKDCIssued struct { |
| 92 | ADChecksum Checksum `asn1:"explicit,tag:0"` |
| 93 | IRealm string `asn1:"optional,generalstring,explicit,tag:1"` |
| 94 | Isname PrincipalName `asn1:"optional,explicit,tag:2"` |
| 95 | Elements AuthorizationData `asn1:"explicit,tag:3"` |
| 96 | } |
| 97 | |
| 98 | // ADAndOr implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.3 |
| 99 | type ADAndOr struct { |
| 100 | ConditionCount int32 `asn1:"explicit,tag:0"` |
| 101 | Elements AuthorizationData `asn1:"explicit,tag:1"` |
| 102 | } |
| 103 | |
| 104 | // ADMandatoryForKDC implements RFC 4120 type: https://tools.ietf.org/html/rfc4120#section-5.2.6.4 |
| 105 | type ADMandatoryForKDC AuthorizationData |
| 106 | |
| 107 | // Unmarshal bytes into the ADKDCIssued. |
| 108 | func (a *ADKDCIssued) Unmarshal(b []byte) error { |
| 109 | _, err := asn1.Unmarshal(b, a) |
| 110 | return err |
| 111 | } |
| 112 | |
| 113 | // Unmarshal bytes into the AuthorizationData. |
| 114 | func (a *AuthorizationData) Unmarshal(b []byte) error { |
| 115 | _, err := asn1.Unmarshal(b, a) |
| 116 | return err |
| 117 | } |
| 118 | |
| 119 | // Unmarshal bytes into the AuthorizationDataEntry. |
| 120 | func (a *AuthorizationDataEntry) Unmarshal(b []byte) error { |
| 121 | _, err := asn1.Unmarshal(b, a) |
| 122 | return err |
| 123 | } |