Assume we have 2 tokens: T1 and T2. S1 - session open with T1, S2 - session open with T2. All sessions logged in as user. S1 creates session object O1.
Can we access session object O1 via S2? That is can we access the session object created by session linked to different token then the token operating session linked to?
The question has raised from following place in cryptoki document: "...That is, if a single application has multiple sessions open with a token, and it uses one of
them to create a session object, then that session object is visible through any of THAT
application’s sessions..." THAT == multiple sessions open with a token ?
I don' think you can access O1 (object that resides inside Token1) via S2 (session open with Token2).
For instance, let's assume an application connects to 2 different tokens and then creates 2 objects:
An AES encryption key on Token 1
A wrappable RSA private key on Token 2
Then, the application commands (on either session) to have the RSA key wrapped by AES key.
That's hardly possible because the two tokens are not aware of each other at all and won't allow that operation.
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.
At the moment I want to implement a method that stores certain data server-side only encrypted. For this procedure is provided that each authorized user receives a private key, with which he can store and read encrypted data. Now it is so that several authorized persons are allowed to look at the same encrypted content. This means that if person A stores data encrypted with his private key, person B (if authorized) can also read this data with his private key.
The idea of implementation:
For all authorized persons, a single symmetric key is generated on the server side. The key is used to encrypt and decrypt plain text data. Now, for each individual claimant, a key pair is generated (public and private). With the public key, the symmetric key is encrypted and stored for the user and there are several of these asymmetrically encrypted symmetric keys on the server. The private key is given to the user (as a file download, HTTPS), which later can be used to decrypt the encrypted symmetric key. Therefore He can upload his private key before writing or reading encrypted data, in a web application (client side) and send it to the server. The Server uses the private Key to encrypt the content of the user and save it, or decrypt older content and send it in plain text to the user.
My problem now is that the weak point is the server, where the private key of the user must first be sent to encrypt and decrypt. There might be someone with access this private key secretly intercept and save.
My question now: Is there an alternative to the approach or does one have to do so if he wants to implement such a procedure? It is important that the data is stored only encrypted. And also this must be implemented with a client web-application and a backend.
Is it possible to store multiple credentials for a given user in Keycloak?
They don't need to be all active/enabled at the same time. The use case for us is rather that we want to store new credentials in advance but don't want to have them active yet. They should be activated/enabled at a later time after some manual user verification.
The Keycloak REST API documentation states that UserRepresentation indeed comprises an array of CredentialRepresentation but in my few tests the GET call wouldn't even return a credentials attribute.
I would say that's impossible to have more credentials for a user.
But you can always implement your own user storage SPI that implements interface CredentialInputValidator, where you can check for the valid password.
Let's say in your DB, you have 2 colums for passwords: pas_col1 and pas_col2, and 1 more column as flag, which tells what column is used for user authentication, so in isValid(RealmModel realm, UserModel user, CredentialInput input) method you can check for your conditions.
Link to SPI: https://www.keycloak.org/docs/3.4/server_development/index.html#_user-storage-spi
I'm using the parse REST API.
I need to setup so that for any requests made:
1) only logged in/authenticated users can Read or Write.
2) users can only access/modify records they own.
My current implementation:
1) using the Application key + REST API key.
2) sending request to user login endpoint, on success returning the user data including the session token
for 2), I'm not doing anything with the session token yet.
I understand that parse has:
1) class based permissions
2) object-level permissions (ACL's)
With Read and Write access on the class level, and by simply using the Application Key + REST API Keys,
anyone with these two keys can access that class (ofcourse, the Master Key has even more "power").
I want to simply say that they can Read and Write on the class level, if they're logged in/authenticated.
And when they Read, Update or Delete, they can only do so if they're owner of the object.
I assume that session token will play a role in the logged in part, and ownership is defined by object-level ACL
Is this correct and how to roughly set this scenario up in parse?
It's not clear to me in the REST API how to handle this (what I think is a common) type of scenario.
Thanks for any feedback
{"ACL":{"$CURRENT_USER":{"read":true,"write":true}}}
above in acl column will mean at the security level, only the creator has RW permissions. No other user can see these records with this ACL attr value regardless of their access on the CLASS level.
OR
you control the accessor predicates in your app. So you can add a column = 'createdBY' of type pointer_to_class_User.
Any queries just contain predicate ..
'where={"createdBy":{"__type":"Pointer","className":"User","objectId":"$CURRENT_USER"}}'
which enforces ( outside row security level ) idea of only getting result sets containing rows for the current-user.
all depends on how you want to use the security layer.
I would do it using the predicates and resort to the ACL only where you may have stuff like SSN's or Salary where as a policy you dont what general read permissions.
I am developing a REST API layer for my application using Zend_Rest_Controller. I have an authenticate method where the clients will pass the apikey and after the key is authorized I have to create a session (for which I'm using new Zend_Session_Namespace(<32 bit unique session key which I'm generating>)) which need to be retrieved in subsequent API calls where the client will pass the same session key which I generated in the previous step.
It looks like Zend uses PHPSESSID variable to retrieve the session object and since my clients use, curl there is no guarantee that the same request object will be used in subsequent calls.
In a nutshell - I want to generate a 32 bit unique string and then use that as a key to store the session object and then use that key to restore my session object in the next call. And in the process I don't want Zend to use the PHPSESSID variable.
Any help will be greatly appreciated!
Cheers
The Zend_Session API documentation lists a setId method:
setId() - set an id to a user specified id
throws: Zend_Session_Exception
access: public static void setId (string $id)
string $id