Skip to content

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

New issue
New issue
Closed
Closed
Support for Kerberos and others as type values of Security Scheme Object#451
@lennybacon

Description

@lennybacon
lennybacon
opened on Aug 28, 2015

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.

Activity

webron

webron commented on Aug 28, 2015

@webron
webron
on Aug 28, 2015
Member

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

lennybacon commented on Aug 28, 2015

@lennybacon
lennybacon
on Aug 28, 2015
Author

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
added
Swagger.Next Proposal
on Aug 28, 2015
webron

webron commented on Aug 28, 2015

@webron
webron
on Aug 28, 2015
Member

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

lennybacon commented on Aug 28, 2015

@lennybacon
lennybacon
on Aug 28, 2015
Author

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

lennybacon commented on Aug 28, 2015

@lennybacon
lennybacon
on Aug 28, 2015
Author

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

dolmen commented on Feb 29, 2016

@dolmen
dolmen
on Feb 29, 2016

Related: #583

webron

webron commented on Feb 29, 2016

@webron
webron
on Feb 29, 2016
Member

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

dolmen

dolmen commented on Mar 1, 2016

@dolmen
dolmen
on Mar 1, 2016

@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

webron commented on Mar 1, 2016

@webron
webron
on Mar 1, 2016
Member

@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

webron commented on Mar 1, 2016

@webron
webron
on Mar 1, 2016
Member

Parent issue: #585

webron
added
Sub Issue
on Mar 1, 2016
darrelmiller

darrelmiller commented on Oct 8, 2016

@darrelmiller
darrelmiller
on Oct 8, 2016
Member

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

webron

webron commented on Mar 3, 2017

@webron
webron
on Mar 3, 2017
Member

Closing as done.

webron
closed this as completedon Mar 3, 2017

23 remaining items

MikeRalphson

MikeRalphson commented on Dec 19, 2018

@MikeRalphson
MikeRalphson
on Dec 19, 2018 · edited by MikeRalphson
Member

Apologies for leaving you hanging, though the swagger-ui repository would probably be the best place to ask, I don't believe Kerberos is supported in swagger-ui's Try It Out console today. Though there might be a hook you could use to implement it...

lennybacon

lennybacon commented on Dec 19, 2018

@lennybacon
lennybacon
on Dec 19, 2018
Author

I just looked at the repo and from the code I guess it will not work. For basic they have a username and password field which means they stuff the header by themselves: https://github.com/swagger-api/swagger-ui/blob/12e350fcad66f7708e6bc3e18d8cb2c9a107bc16/src/core/components/auth/basic-auth.jsx

keith6014

keith6014 commented on Dec 22, 2018

@keith6014
keith6014
on Dec 22, 2018

@MikeRalphson
No problem! Thanks for the idea and keep up the good work.

@lennybacon
yeah, doesn't seem so. Thanks for looking.

Kerberos/SSO is the single most feature most of our user base has required. I will consider asking swagger-ui group https://github.com/swagger-api/swagger-ui

MikeRalphson

MikeRalphson commented on Dec 22, 2018

@MikeRalphson
MikeRalphson
on Dec 22, 2018
Member

We're actively looking at security improvements for v3.1 so let us know if Kerberos / SSO needs further support in the spec.

keith6014

keith6014 commented on Dec 22, 2018

@keith6014
keith6014
on Dec 22, 2018

Yes. Kerberos is needed. Its used quite heavily in the world. So far in the 3 large companies I worked for Kerberos was the primary auth method.

MikeRalphson

MikeRalphson commented on Dec 22, 2018

@MikeRalphson
MikeRalphson
on Dec 22, 2018
Member

Technically, the spec supports it today, but tooling is free to support whichever auth schemes they want. But do we require any new metadata fields to make support actually work?

stevendearborn

stevendearborn commented on Feb 5, 2019

@stevendearborn
stevendearborn
on Feb 5, 2019

According to the OAS 3.0.2 documentation, all of the IANA-registered HTTP authentication schemes are supported, with the qualification as to this relates to the authorization header. As posted on Feb 9, 2018 these are not supported by the Swagger Editor or UI tooling as was mentioned. Also, the 'in' property is not valid when type is set to 'http'; only scheme is valid. Presently, the only option is to use type: http, scheme: Custom, use vendor extensions (i.e. x-) to stipulate the remainder of the security scheme, and write a very clear description for application developers. There is a lot of work to be done here, potentially modifying the OAS 3.x JSON schema but mostly the tooling.

I would like to open another issue to expand the concept of 'security scheme' not to just authentication and authorization but to other security schemes such as data integrity/digital signature, non-repudiation, PKI/digital certificates, etc.. This would create a more 'normalized' JSON schema structure in the OAS specification while allowing flexibility in the tooling implementations. In absence of defining security schemes for these, the concepts, and related input and output parameters are becoming conflated with the actual resource-related inputs and outputs. The separation of these concepts would make APIs more readable especially when the complexities of API security are required.

MikeRalphson

MikeRalphson commented on Feb 5, 2019

@MikeRalphson
MikeRalphson
on Feb 5, 2019
Member

expand the concept of 'security scheme' not to just authentication and authorization but to other security schemes such as data integrity/digital signature, non-repudiation, PKI/digital certificates, etc.

Some work on exactly this is being undertaken at the moment. Probably the best thing is to join one of the Thursday open TSC calls if the time works for you, or I can dig out a link to a recording of a previous call where the work-in-progress was presented.

stevendearborn

stevendearborn commented on Feb 5, 2019

@stevendearborn
stevendearborn
on Feb 5, 2019

Thank you @MikeRalphson yes I would be interested.

MikeRalphson

MikeRalphson commented on Feb 6, 2019

@MikeRalphson
MikeRalphson
on Feb 6, 2019
Member

@stevendearborn https://zoom.us/recording/share/PBwsPKe6OprJMcAx6bWs5Y4ySGOGnOsu7-hZGAoTS2uwIumekTziMw

shockey
mentioned this on Feb 11, 2019
StephenCoady
mentioned this on Feb 25, 2020
lennybacon

lennybacon commented on May 12, 2020

@lennybacon
lennybacon
on May 12, 2020
Author

As I read here swagger 3 DOES support Kerberos:

OpenAPI uses the term security scheme for authentication and authorization schemes. OpenAPI
3.0 lets you describe APIs protected using the following security schemes:

  • HTTP authentication schemes (they use the Authorization header):
    • Basic
    • Bearer
    • other HTTP schemes as defined by RFC 7235 and HTTP Authentication Scheme Registry
lennybacon
closed this as completedon May 12, 2020
earth2marsh
mentioned this on May 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @MikeRalphson@dolmen@webron@lennybacon@darrelmiller

        Issue actions
          Support for Kerberos and others as type values of Security Scheme Object · Issue #451 · OAI/OpenAPI-Specification