How is X.509 certificate for a confidential identity signed? Does the node signs it with it's node certificate? Or is it signed with node's well-known signing identity?
How is it avoided that the certification chain can not be followed back from the signature created by the confidential signing identity? For instance, in the cash usecase where historic states back to the issuer have to be presented in order to be able to validate cash transactions.
The node's well-known identity issues and signs certificates for each one of its confidential identities.
It only shares the certificate chain linking a confidential identity back to its well-known identity on a need-to-know basis.
If a node inspects a transaction chain where a confidential identity has been used for which they have not received the certificate chain, the node will simply see an anonymous public key that they cannot link to a well-known identity.
Related
I'm building an identity service using PKI and MTLS for authentication.
I use AWS ACM PCA for private certificate authority and AWS KMS for key pairs.
I use the private key created by KMS to sign the Certificate Signing Request that's sent to PCA for creating a client certificate.
The client certificate is then bundled together with the CA certificate chain and the private key in PKCS#12 format and returned to the user which is used to authenticate the user.
We also want the user to be able to sign data, e.g. a json string a PDF file e.t.c.
According to KMS documentation they recommend different types of keys for signing and encryption.
So, do I need different certificates for signing data and if so, what's the point of the signing certificate if the data is signed with the private key and the authentication is made with the client certificate?
We want to be able to authenticate the user using one certificate which is not protected by a password and require password for signing, so I guess we need different PKCS#12 stores?
In corda, In order to hide identity of corda nodes in transaction, Confidential Identities being used. As per corda documentation, Confidential Identities issued by Well Known Identity Certificates.
Below are few questions related to corda confidential Identity :
How notary (Service Identity) checks signature on transaction if it consist of confidential key?
How corda linked up Well-known Identity with confidential Identity? What extra information required to linked up confidential identity with well-known identity?
If perform transaction between PartyA and PartyB with confidential identity using SwapIdentityFlow, now perform same transaction between PartyB and PartyC, will PartyC resolves all dependency including confidential identities from PartyB. As per walking transaction chain dependency resolved from proposer of transaction, so without any IdentitySyncFlow will it work?
How nodes verify signatures on SignedTransaction ? Is it only based on public key?
Thank you in advance.
The required signers on a transaction are listed as public keys, not Party objects. If you want to sign a transaction using a confidential identity, you just list that confidential identity's public key as a required signer on the transaction instead of your well-known identity's public key. Then verifying the signature does not require knowing the corresponding identity.
Each confidential identity is linked to the corresponding well-known identity using a certificate chain. However, this certificate chain is only distributed on a need-to-know basis, so that only specific nodes can link the confidential identity to a well-known identity.
Walking the chain does not require resolving confidential identities to well-known identities. Thus PartyB and PartyC can transact without PartyC knowing that PartyA was involved earlier in the chain.
Yes. See the answer to 1.
We have working ADFS 2016 server with over 100 clients as claims provider trusts. Now I need to join to a local government SAML2 system, which is common solution for many goverment bodies. It is compatible with our ADFS setup except they require (without any valid reason) us to use special goverment signed certificates as a token signing (and possibly encryption) certificate. With over 100 existing customer, which do not all update from our metadata automatically, I do NOT want to change our current token signing/encryption certificates in our published metadata.
Is there some way to handle this situation in ADFS server?
Can I install this goverment token signing certificate to the ADFS server as a second certificate and make it so that it is NOT published in our metadata?
And this second certificate should be used only with some selected claim provider trusts so that ADFS server by default uses our current certificate but uses the goverment certificate for logins from selected claim provider trusts that are linked to government SAML2 system?
Or is the completely different ADFS server our only option?
Thanks.
No - IDP only use one certificate. Azure AD works exactly the same way.
Your only option is another IDP.
This doesn't have to be ADFS - just another IDP.
Sorry for my bad English. I have read about Security and understood how RSA work.
But how can RSA keep Authentication, a man in middle can use public key and fake message back. And how it keep Non-repudiation, someone who send you a message encrypted by public key can say that it is not from him and it is faked?
There is some math behind RSA PKI (public key infrastructure) but I will try to keep it simple. Though this scenario is described in many other sites and questions/answers. What exacly you don't understand?
The idea is, that it is easy to encrypt with the public key, but not possible to decrypt. The decryption is possible only with the private key.
Seems your question is aiming somewhere else. What you are missing (and is not part of the RSA itself) are certificates. Certificates may use RSA. A certificate is information about a holder of the public key. Still - there is a problem. If an entity (person, website) provides you a certificate, how can you be sure the cretificate really belongs to the website, person or organization?
That's why there is defined term Certificate Authority (CA) - there are organizations which you (or your browser) should trust.
So when a website creates its RSA keypair, some certificate authority issues a signed certificate (bound to the public key) that the certificate is really from the website, person or organization.
a man in middle can you public key and fake message back.
Your client (browser, application) must have a list of trusted Certificate Authorities. Usually it is already stored in your system. So the real web page can provide its public key and certificate and use encryption based on the public key. The browser checks that the certificate is valid and it is issued by a trusted authority.
The "man in the middle" would not be able to provide valid and trusted (signed by CA) certificate.
And how it keep Non-repudiation, someone who send you a
message encrypted by public key can say that it is not
from him and it is faked?
The same comes to the signing. Once data are signed (or authenticated) using the private key, the signature can be validated by anyone using the public key. A certificate is bound to the public key. Usualy the signing certificate is issued only when identity is verified by the certificate authority (for example for electronic ID cards, code signing certificates, ..). So anyone could verify the signature was created by someone who was verified by a trusted authority.
Assume there are two companies: A.NET which is a .NET shop and B.Java which is a Java shop.
Users in each company need to access the other company's web sites so the two companies set up Federation using ADFS and Oracle Identity Federation or OpenSSO Federation.
In the .NET world, the attributes are accessed as claims inside IClaimsPrincipal and IClaimsIdentity.
In the Java world, the attributes are accessed as HTTP headers.
Does the Federation infrastructure do this mapping automatically i.e.
If a A.NET user accesses a B.Java site do they get their attributes as claims?
If a B.Java user accesses a A.NET site do they get their attributes as headers?
Assuming you can use WS-Federation on both sides, then in both cases the main artifact you would be dealing with is a SAML token.
In general, your federation infrastructure is completely independent of the application stack. ADFS would issue SAML tokens in either case (for the Java app and for the .NET app). OIF would also have to issue SAML tokens for both sets of users.
In the .NET world, WIF will parse/validate, etc. the SAML token into a .NET object model that represents the information in it (the claims, the issuer, etc). That object model is the ClaimsPrincipal (and all related interfaces and types). You would have to look at the WIF equivalent on the java world. But in either case, the input is a SAML token.
In your scenario it is likely that there will be a token transformation in both STSs:
For the .NET app:
1- user from the B company authenticates on OIF and gets a SAML token for company A
2- user sends token to ADFS
3- ADFS reads the token from B, validates and issues a new token (potentially and very likely adding/transforming/removing claims)
4- user sends the transformed token to app A
The sequence from a user in A accesing the java app on B is exactly the same. Notice there's a bidirectional trust in this case (Company A trusts issuer in B and viceversa)