Support for Kerberos and others as type values of Security Scheme Object

[lennybacon]

We want to use swagger for an internal system. The authentication mechanism we use is Kerberos.

Currently this is not a supported type value of the Security Scheme Object.

To support Negotiate (for Kerberos), NTML or Digest (as values for the WWW-Authenticate-Header) it would be nice if the type values would be added to the specification.

[webron]

What additional fields would be required to support Kerberos or other schemes you had in mind? As you can see in the spec, basic has no additional metadata, apiKey has the name of the field and where it's located, oauth2 has the flow type and based on the flow the additional token urls.

[lennybacon]

Digest, NTLM and Negotiate work like basic (RFC 2617 contains basic and digest http://www.ietf.org/rfc/rfc2617.txt)

in HTTP its

GET --->
< --- 401 WWW-Authenticate [Basic|Digest|NTLM|Negotiate] 
GET ---> Authorization: [Basic|Digest|NTLM|Negotiate] [TOKEN]
<--- 200 | 304

As you said is swagger basic has no additional metadata. So as far as I can see it's just adding the values digest, ntml, negotiate as allowed for types of the Security Scheme Object.

[webron]

I wonder whether we should just add those as types or possibly group them all under the access type and have another field specifying the specific type. Don't know if there are any benefits to either approach (though my suggestion is more verbose).

As a side note, and possible workaround for now, you can use vendor extensions to specify the specific type. Just set it to type basic, and add something like x-extended-type: digest.

[lennybacon]

I think we are already at the right place as OAUTH uses the same mechanism to authenticate (when headers are used) and should just add them:

GET ---> Authorization: Bearer [TOKEN]
<--- 200 | 304

[lennybacon]

And as we are on the authentication topic... What about client certificates? Had that in mind yet? If not we should consider to include it when extending the auth types.

[dolmen]

Related: #583

[webron]

How is #583 related to this and not a duplicate of this?

[dolmen]

@webron This ticket is about Kerberos and WWW-Authenticate header. #583 is about the Authorization header.
They are different use cases but they are related as ideally a single common solution could fix both.

As a user I don't think it is my task to decide when tickets must be grouped because I don't have your global vision of the issues.

[webron]

@dolmen of course, I much rather people open new issues than not comment at all. If issues are related, it may make sense to expand the discussion on the issue rather than open a new ticket, but either works - it's no big deal most of the times.

Sometimes the differences are not clear - was just checking how the issues differ 😉

[webron]

Parent issue: #585

[darrelmiller]

The pr #807 now allows you to specific the scheme in the security definition, so you can specify the negotiate scheme.

[webron]

Closing as done.