When working with Hashicorp Vault one can see token details with
vault token lookup --accessor secret
but is it possible to actually see this token's value ?
No, you cannot. This is for security reason. Otherwise, you will not be able to create a new (child) token and share it with someone, cause in this case lookup will be able to reveal your (parent) token, that is not acceptable.
In general, the output for lookup command contains id part. This is the token value. For lookup command with --accessor flag id is always n/a in response.
Related
I'm having hard time understanding OIDC that I'm asking here.
[Current Understanding]
ID Token (Based on JWT)
[REQUIRED]
iss (Issuer) : OPurl
sub (Subject Identifier) : unique identifier
aud (Audience) : Unique Client ID which OP provides beforehand
exp (Expires at) : When token expires
iat (Issued at) : When token is issued
[OPTIONAL]
nonce : string value used to associate a client session with ID token (REQ for Implicit Flow)
preferred_username : Shorthand name by which the End-User wishes to be referred to at the RP (The RP MUST NOT rely upon this value being unique)
Sample Token
{"access_token":"SlAV32hkKG","token_type":"bearer","expires_in":3600,"id_token":"eyJ0...","refresh_token":"8xLOxBtZp8"}
Authorization Code Flow (/authorize GET => /token POST) : contains refresh_token and is in JSON form
Implicit Flow (/authorize GET) : does not contain refresh_token and is responsed in fragment mode
Sample ID Token
Header (Base64 Decoded) : {"typ":"JWT","alg":"RS256","kid":"sdfikhRETlknsdfollksdf324lhk"}
Payload (Base64 Decoded) : {"iss":"OPurl","aud":"ClientID","sub":"1234567890","exp":"1665666710","iat":"1665666790"}
Signature : ggW8hZ...zqg
[Question]
In OIDC Core Spec, sub(subject identifier) is a "locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client".
In JWT Spec, it can either be locally unique in the context of the issuer or be globally unique.
Here I have a globally unique User ID. (Let's say 1234567890)
User uses this ID for client A, B, C... everywhere.
No others can use this ID.
Can sub be that ID itself? ("sub":"1234567890")
Or Should sub be like a mix of a random string with the id and preferred_username should be the ID itself? (Keycloak for example, returns the token like {"sub":"f:636436-348762gyu-234786234:1234567890", "preferred_username":1234567890})
I'm not really sure what it means to be "never reassigned identifier within the Issuer for the End-User"...
Any help would be appreciated.
Please let me know if my current understanding is wrong!
I am going to answer with the assumption you are the developer of a JWT producer.
Based on your comments you may also be the developer of the JWT consumer, which makes me wonder why you are choosing OIDC/JWT for this single identity flow. Either way I will respond with context of producer where the consumers are multiple identities authenticating with you, an identity provider, and you are simply coding the OIDC as an JWT producer.
Here I have a globally unique User ID. (Let's say 1234567890)
This is not appropriate if:
a) this user input of any kind (they register their own username)
b) the user may edit (or request an edit) to the value, e.g. an email address or user handle as a username
c) the numeric example it taken literally, the identifier should not be sequential or attackers can enumerate them easily.
It is common the aud and sub are kept associated in server persistent state, and later the JWK identifier (kid) will be set from the key alias (aud or sub for consistency and simplicity) in the store.
Therefore it is quite important to make the sub immutable, server generated, and this will help you to never orphan a key that would cause significant issues in practice.
It means that the subject identifier is a value that should never ever change.
It should be a unique value within your system.
Unlike preferred_username or email or name.
We use vault to store our credentials, I've successfully grabbed S3 Access key ID and Secret Access key using the vault API, and used channelMap.put to create mappings: ${access_key} and ${secret_key}.
aws_s3_file_writer
However when I use these in the S3 file writer I get the error:
"The AWS Access Key Id you provided does not exist in our records."
I know the Access Key Id is valid, it works if I plug it in directly in the S3 file writer destination.
I'd appreciate any help on this. thank you.
UPDATE: I had to convert the results to a string, that fixed it.
You can try using the variable to a higher map. You can use globalChannelMap, globalMap or configurationMap. I would use this last one since it can store password not in plain text mode. You are currently using a channelMap, it scope is only applied to the current message while it is traveling through the channel.
You can check more about variable maps and their scopes in Mirth User guide, Section Variable Maps, page 393. I think that part of the manual is really important to understand.
See my comment, it was a race condition between Vault, Mirth and AWS.
We are facing issue with fetching secrets from Hashicorp Vaullt. Client is actually using role_id and secret_id to auth in Vault. We also use wrapping function for secret_id, so once secret_id is fetched from Vault, it's wrapped and has to be unwrapped to get real secret_id.
Now problem is that wrapping token obtained from Vault has number of usage 1. Meaning that secret_id can be unwrapped only once. When we try 2nd time to unwrap, it is failing. And reason is number of usace for such generated token which is 1 by default.
Key Value
--- -----
accessor LctZYfQyzJVleDb41l7mACu5
creation_time 1603924396
creation_ttl 240h
display_name n/a
entity_id n/a
expire_time 2020-11-07T22:33:16.378745728Z
explicit_max_ttl 240h
id s.ajjvwjfjtTedj7xaeGW1B1WL
issue_time 2020-10-28T22:33:16.378758503Z
meta <nil>
num_uses 1
orphan true
path auth/approle/role/img/secret-id
policies [response-wrapping]
renewable false
ttl 239h58m30s
type service
This is making a lot of issues for us. Is there a way to increase, or set as unlimited number od wrap token usage?
Thank you!
The point of wrapping is that it is only unwrappable once. If you want a token that allows access to a secret for an extended period, then you want a 'regular' token. So create a policy that allows access only to the secret_id, create a new token with only that policy attached, and store that token. Now you have a token that you can use to request the secret_id secret from Vault.
Im looking at the new Keycloak Beta 4 API. When i get the users account information, what is referred to as 'id' in the web ui comes back as 'sub' in the account object.
{ sub: '25a37fd0-d10e-40ca-af6c-821f20e01be8',
name: 'Barrack Obama',
preferred_username: 'obama#whitehouse.gov',
given_name: 'Barrack',
family_name: 'Obama',
email: 'obama#whitehouse.gov' }
What is 'sub' and is this a safe uuid to map database objects to?
As per the keycloak documentation
Anatomy of Action Token
Action token is a standard Json Web Token signed with active realm key where the payload contains several fields:
typ - Identification of the action (e.g. verify-email)
iat and exp - Times of token validity
sub - ID of the user
azp - Client name
iss - Issuer - URL of the issuing realm
aud - Audience - list containing URL of the issuing realm
asid - ID of the authentication session (optional)
nonce - Random nonce to guarantee uniqueness of use if the operation can only be executed once (optional)
Please refer the following link https://www.keycloak.org/docs/latest/server_development/index.html#_action_token_anatomy
Reason may be they want to retain the uniqueness in the name.
In addition to the previous answer, inside JWT tokens, sub refers to subject. The reason is that those tokens can be used in various cases, including authorization. That means that id sometimes might not be "the unique identifier" but might be anything, including repeatable destinations. Basically, a naming convention JWT follows, regardless of Keycloak.
I am trying to limit a SAP user´s access to transaction SOST. He may only have read/display permissions. I have tried to limit the authorizations in a role using the authorization objects S_TCODE, S_DATASET, S_OC_ROLE and S_OC_SEND. But it is not sufficient.
Any ideas?
You can check at SU24 the objects related to SOST TCode. I think this ones may be the ones you're looking for:
S_OC_DOC; S_OC_ROLE; S_OC_SEND; S_OC_SOSG; S_OC_TCD
Try to use SOSG transaction instead. This transaction corresponds to transaction SOST but makes additional authorization checks.
I'd rather do the above requirement in this way:
Give to user authorization to T-code SOSG (via S_TCODE authorization object)
Create separate user group and add the relevant users to this group
Use authorization object S_OC_SOSG where you should strictly specify this group and type of send requests to display
You can create an PFCG (Role Maintenance) role with authorization field S_TCODE to limit the transaction codes could be executed by a user.