Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bearer token doesn't have any issuer field inside #266

Closed
roman-khimov opened this issue Jul 25, 2023 · 0 comments
Closed

Bearer token doesn't have any issuer field inside #266

roman-khimov opened this issue Jul 25, 2023 · 0 comments
Labels
enhancement Improving existing functionality I3 Minimal impact S2 Regular significance U4 Nothing urgent
Milestone
v2.16.0

Comments

@roman-khimov
Copy link
Member

It's derived from the key like in https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go/bearer#ResolveIssuer, but this defeats neofsid or any other non-standard account mapping scheme.
@roman-khimov roman-khimov mentioned this issue Jul 25, 2023
Merged
@roman-khimov roman-khimov added U4 Nothing urgent S2 Regular significance I3 Minimal impact enhancement Improving existing functionality labels Dec 20, 2023
cthulhu-rider added a commit that referenced this issue Feb 26, 2024
@cthulhu-rider
acl: Extend BearerToken message with issuer field
1951b5c 
Previously, `BearerToken` message had no explicit field for the token
issuer. This could become a limitation on subject identification because
only public key derivation was supported. To prevent this, `issuer`
field is added.

Closes #266.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
@roman-khimov roman-khimov added this to the v2.16.0 milestone Feb 26, 2024
cthulhu-rider added a commit to nspcc-dev/neofs-api-go that referenced this issue Mar 4, 2024
@cthulhu-rider
acl: Support issuer field in bearer token
c97dae0 
The field was added within nspcc-dev/neofs-api#266.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 4, 2024
@cthulhu-rider
bearer: Add new issuer-related methods
0710e07 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. SDK should
provide functionality to work with it.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 5, 2024
@cthulhu-rider
bearer: Add new issuer-related methods
c96853a 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. SDK should
provide functionality to work with it.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Set issuer explicitly on signing
435df25 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. Now SDK
provides getter and setter for it.

Previously, `Token` type accepted `neofscrypto.Signer` parameter in
`Sign` method to calculate and set signature of the bearer token.
Obviously, the method did not set nonexistent issuer field. The only way
to access the issuer was `ResolveIssuer` method resolving user ID from
the public key.

Now `Sign` method accepts parameter of `user.Signer` type to
additionally set issuer field. This is a breaking change overall, but
still needed for stable system authorization and library usage.

`ResolveIssuer` method is marked as deprecated in favor of new `Issuer`
one.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Accept issuer ID in SignedData method
02dd8ff 
After protocol extension nspcc-dev/neofs-api#266,
bearer token's signed data include issuer ID. Since
435df25, `Sign` method accepts `user
.Signer` parameter. In order to stabilize UX of so-called static
signing, caller should be forced to specify who's going to sign the
token. While this is a breaking change, it will work better than
doc requirement to call `SetIssuer` in advance.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Set issuer explicitly on signing
eecc97f 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. Now SDK
provides getter and setter for it.

Previously, `Token` type accepted `neofscrypto.Signer` parameter in
`Sign` method to calculate and set signature of the bearer token.
Obviously, the method did not set nonexistent issuer field. The only way
to access the issuer was `ResolveIssuer` method resolving user ID from
the public key.

Now `Sign` method accepts parameter of `user.Signer` type to
additionally set issuer field. This is a breaking change overall, but
still needed for stable system authorization and library usage.

`ResolveIssuer` method is marked as deprecated in favor of new `Issuer`
one.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Accept issuer ID in SignedData method
8b2ad4b 
After protocol extension nspcc-dev/neofs-api#266,
bearer token's signed data include issuer ID. Since
435df25, `Sign` method accepts `user
.Signer` parameter. In order to stabilize UX of so-called static
signing, caller should be forced to specify who's going to sign the
token. While this is a breaking change, it will work better than
doc requirement to call `SetIssuer` in advance.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Set issuer explicitly on signing
ee28588 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. Now SDK
provides getter and setter for it.

Previously, `Token` type accepted `neofscrypto.Signer` parameter in
`Sign` method to calculate and set signature of the bearer token.
Obviously, the method did not set nonexistent issuer field. The only way
to access the issuer was `ResolveIssuer` method resolving user ID from
the public key.

Now `Sign` method accepts parameter of `user.Signer` type to
additionally set issuer field. This is a breaking change overall, but
still needed for stable system authorization and library usage.

`ResolveIssuer` method is marked as deprecated in favor of new `Issuer`
one.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Accept issuer ID in SignedData method
f275940 
After protocol extension nspcc-dev/neofs-api#266,
bearer token's signed data include issuer ID. Since
435df25, `Sign` method accepts `user
.Signer` parameter. In order to stabilize UX of so-called static
signing, caller should be forced to specify who's going to sign the
token. While this is a breaking change, it will work better than
doc requirement to call `SetIssuer` in advance.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Set issuer explicitly on signing
6272a4b 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. Now SDK
provides getter and setter for it.

Previously, `Token` type accepted `neofscrypto.Signer` parameter in
`Sign` method to calculate and set signature of the bearer token.
Obviously, the method did not set nonexistent issuer field. The only way
to access the issuer was `ResolveIssuer` method resolving user ID from
the public key.

Now `Sign` method accepts parameter of `user.Signer` type to
additionally set issuer field. This is a breaking change overall, but
still needed for stable system authorization and library usage.

`ResolveIssuer` method is marked as deprecated in favor of new `Issuer`
one.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 18, 2024
@cthulhu-rider
bearer: Accept issuer ID in SignedData method
05a9ccb 
After protocol extension nspcc-dev/neofs-api#266,
bearer token's signed data include issuer ID. Since
435df25, `Sign` method accepts `user
.Signer` parameter. In order to stabilize UX of so-called static
signing, caller should be forced to specify who's going to sign the
token. While this is a breaking change, it will work better than
doc requirement to call `SetIssuer` in advance.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
cthulhu-rider added a commit to nspcc-dev/neofs-sdk-go that referenced this issue Mar 25, 2024
@cthulhu-rider
bearer: Set issuer explicitly on signing
06e0977 
Dedicated field for the bearer token issuer was recently added to the
protocol nspcc-dev/neofs-api#266. Now SDK
provides getter and setter for it.

Previously, `Token` type accepted `neofscrypto.Signer` parameter in
`Sign` method to calculate and set signature of the bearer token.
Obviously, the method did not set nonexistent issuer field. The only way
to access the issuer was `ResolveIssuer` method resolving user ID from
the public key.

Now `Sign` method accepts parameter of `user.Signer` type to
additionally set issuer field. This is a breaking change overall, but
still needed for stable system authorization and library usage.

`ResolveIssuer` method now dual: it starts like `Issuer` and falls back
to the old behavior when field is missing.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
@cthulhu-rider cthulhu-rider mentioned this issue Apr 1, 2024
Open
@roman-khimov roman-khimov mentioned this issue Sep 3, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Improving existing functionality I3 Minimal impact S2 Regular significance U4 Nothing urgent
Projects
None yet
Milestone
v2.16.0
Development

No branches or pull requests
1 participant
@roman-khimov