Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-29370

Add ability to filter TokenSources by external conditions

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I've got into the situation, when there're several extensions of AuthenticationTokenSource matching the same credentials class. In such case I would like to be able to filter proposed sources by an external matcher.

      Example: user/password authorization with different connection types (basic, digest, etc.)

        Attachments

          Activity

          Hide
          stephenconnolly Stephen Connolly added a comment - - edited

          In my view filtering token sources in the consumer of this API is against the spirit of the API.

          The consumer should not be required to know which token sources are valid and which are not valid. If it knew which token sources were valid it would just use them directly.

          The point of this API is to enable the consumer to specify the context within which they want to use the token and then have the credentials (of a type unknown to the consumer) be converted (by a converter of a type unknown to the consumer) into a token (of a type known to the consumer)

          So the root use case here is something like this:

          1. As a consumer I am going to authenticate a XYZHttpConnection using Digest authentication, please give me a matcher for credentials that can be used in this context... now please convert this specific credential into the XYZHttpAuthenticator instance

          In the 1.1 version of the authentication tokens API we assume that there would be separate classes for a BasicXYZHttpAuthenticator and a DigestXYZHttpAuthenticator, but that is an arrogant assumption to make. We should not be assuming anything of the library we are mapping to. In other words, in the context of this example the library should be free to have on and only one XYZHttpAuthenticator class that perhaps gas a getScheme() method to differentiate between basic and digest authentication.

          So the real solution for this issue is to allow a more fine grained specification of the context within which we will use the token. Thus instead of saying "we want a XYZHttpAuthenticator token", we should be saying "we want a XYZHttpAuthenticator token for the purpose of digest authentication"

          Show
          stephenconnolly Stephen Connolly added a comment - - edited In my view filtering token sources in the consumer of this API is against the spirit of the API. The consumer should not be required to know which token sources are valid and which are not valid. If it knew which token sources were valid it would just use them directly. The point of this API is to enable the consumer to specify the context within which they want to use the token and then have the credentials (of a type unknown to the consumer) be converted (by a converter of a type unknown to the consumer) into a token (of a type known to the consumer) So the root use case here is something like this: 1. As a consumer I am going to authenticate a XYZHttpConnection using Digest authentication, please give me a matcher for credentials that can be used in this context... now please convert this specific credential into the XYZHttpAuthenticator instance In the 1.1 version of the authentication tokens API we assume that there would be separate classes for a BasicXYZHttpAuthenticator and a DigestXYZHttpAuthenticator , but that is an arrogant assumption to make. We should not be assuming anything of the library we are mapping to. In other words, in the context of this example the library should be free to have on and only one XYZHttpAuthenticator class that perhaps gas a getScheme() method to differentiate between basic and digest authentication. So the real solution for this issue is to allow a more fine grained specification of the context within which we will use the token. Thus instead of saying "we want a XYZHttpAuthenticator token", we should be saying "we want a XYZHttpAuthenticator token for the purpose of digest authentication"
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
          src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
          http://jenkins-ci.org/commit/authentication-tokens-plugin/4e5848a765d2d19c2059aac8147a74dfd28ce80e
          Log:
          JENKINS-29370 Add the concept of an authentication token context

          • Filtering token sources (as originally requested in JENKINS-29370) in the consumer of this API is against the spirit of the API.
          • The consumer should not be required to know which token sources are valid and which are not valid. If it knew which token sources were valid it would just use them directly.
          • The point of this API is to enable the consumer to specify the context within which they want to use the token and then have the credentials (of a type unknown to the consumer) be converted (by a converter of a type unknown to the consumer) into a token (of a type known to the consumer)
          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java http://jenkins-ci.org/commit/authentication-tokens-plugin/4e5848a765d2d19c2059aac8147a74dfd28ce80e Log: JENKINS-29370 Add the concept of an authentication token context Filtering token sources (as originally requested in JENKINS-29370 ) in the consumer of this API is against the spirit of the API. The consumer should not be required to know which token sources are valid and which are not valid. If it knew which token sources were valid it would just use them directly. The point of this API is to enable the consumer to specify the context within which they want to use the token and then have the credentials (of a type unknown to the consumer) be converted (by a converter of a type unknown to the consumer) into a token (of a type known to the consumer)
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
          src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
          http://jenkins-ci.org/commit/authentication-tokens-plugin/34165eef209c2af53feb1b25151b54e64b43cd57
          Log:
          Merge pull request #3 from jenkinsci/jenkins-29370-context

          JENKINS-29370 Add the concept of an authentication token context

          Compare: https://github.com/jenkinsci/authentication-tokens-plugin/compare/ac2edca70e1e...34165eef209c

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java http://jenkins-ci.org/commit/authentication-tokens-plugin/34165eef209c2af53feb1b25151b54e64b43cd57 Log: Merge pull request #3 from jenkinsci/jenkins-29370-context JENKINS-29370 Add the concept of an authentication token context Compare: https://github.com/jenkinsci/authentication-tokens-plugin/compare/ac2edca70e1e...34165eef209c
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
          src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
          http://jenkins-ci.org/commit/authentication-tokens-plugin/2f8268d5a0eaf7844743de1e73d08816a7bc62d4
          Log:
          JENKINS-29370 Need the ability to convert the best match of a selection of credentials

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java http://jenkins-ci.org/commit/authentication-tokens-plugin/2f8268d5a0eaf7844743de1e73d08816a7bc62d4 Log: JENKINS-29370 Need the ability to convert the best match of a selection of credentials
          Hide
          stephenconnolly Stephen Connolly added a comment -

          The API in 1.2 was adjusted to address root use case requirement

          Show
          stephenconnolly Stephen Connolly added a comment - The API in 1.2 was adjusted to address root use case requirement

            People

            Assignee:
            oleg_nenashev Oleg Nenashev
            Reporter:
            oleg_nenashev Oleg Nenashev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: