The following aries RFC #36 mentions an opional step "propose-credential" https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md#propose-credential
Unfortunately I cannot find the method in the rust library: https://github.com/hyperledger/indy-sdk/blob/f9eb2cf17b51584f875c4707094256a96656e7b8/wrappers/rust/indy-sys/src/anoncreds.rs
I was expecting to see something like: indy_issuer_create_credential_proposal in the same way there is a indy_issuer_create_credential_offer.
What's the best way to generate a credential proposal with lib-indy?
thanks for your help!
The logic of the propose-credential is application-specific and, as of today, not yet part of the Hyperledger Indy library. You are right when you say that there is no function for it, as Indy only provides functions to offer a credential, request a credential, and issue a credential.
As one note in the doc says:
Note: In Hyperledger Indy, where the request-credential message can
only be sent in response to an offer-credential message, the
propose-credential message is the only way for a potential Holder to
initiate the workflow.
So this means that you can implement the format specified in the credential proposal message, and handle it at the application layer, likely before the create_credential_offer function is called.
Related
According to the Firebase documentation about onCall 'callable' functions :
The functions.https.onCall trigger automatically deserializes the request body and validates auth tokens.
Also, according to the Firebase callable Functions protocol specification:
If the auth token supplied in the request is invalid, the request is rejected with 401 Unauthorized, with an error code of UNAUTHENTICATED.
However, I experimented that it's possible to call a function with invalid Authorization header like Authorization: fooBar or worst, without providing it:
curl -X POST --location https://my-test-app.cloudfunctions.net/hello -d "{data:{})"
The function responds "Hello world!" as expected (http 200 'ok').
Of course, context.auth is undefined in that case, but still, it's considered as valid.
This is very misleading and dangerous as developers can think their functions are protected by default, but they aren't : anyone can call it publicly.
I know about the default "AllUser" access credential on the firebase deployed function, nevertheless the documentation is confusing.
Did I missed anything to enable or configure to activate a concrete out-of-the-box token validation?
A missing auth token is never an error for a callable function. All callable functions are considered publicly accessible.
If you don't want the function to do its work unless a valid auth token is presented in the request, then you should simply write a few lines of code to check that and bail early. The code for that is actually provided in the page of documentation that you linked.
// Checking that the user is authenticated.
if (!context.auth) {
// Throwing an HttpsError so that the client gets the error details.
throw new functions.https.HttpsError('failed-precondition', 'The function must be called ' +
'while authenticated.');
}
If you feel that some functionality is not working as described in the documentation, file a bug report on GitHub with your steps to reproduce the problem.
I am trying to obtain an access token for use with Google APIs using the up-to-date expo-auth-session package.
It works fine to fetch an id_token via useAuthRequest({responseType: "id_token", ...}) or useIdTokenAuthRequest({...})
However, when trying useAuthRequest({responseType: "code", ...}), I get the following error:
[Unhandled promise rejection: Error: The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.]
Does anyone know what is missing from the request? I am using the Expo Go app currently, so I'm not sure if that prevents obtaining an access token. Currently digging through the package's source code...
Add the following two props to useAuthRequest
shouldAutoExchangeCode: false,
clientSecret: 'any_bogus_value!'
shouldAutoExchangeCode will prevent the code from being exchanged and send it back to you in the response.
clientSecret will simply trigger and if check to be true in the providers source code that will avoid that error you specified being returned.
Note that in general it is not a good practice to avoid errors, but in this case, I feel like the error is being shown in error itself!
I'm sorry in advance if something bring you here and I talk about a platform that's not really well-known over the world despite featuring a well-known person dancing in their commercial.
It's Shopee Open Platform API I talk about. I was trying to follow very properly their instruction here.
https://open.shopee.com/documents?module=63&type=2&id=51
But stuck instantly at step 5 : Shop Authorization. First, I've been given a test partner id, a test key, and I need to set manually the test redirect URL. I have to generate authorization token from all given information. Firstly I need to create a token base string by concatenating the test key with URI component encoded string of the URL. It turns into something like this.
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
To generate the authorization token, it says I need to do hexencode(sha256(token_base_string)). It returned a very long integer.
32373935663639356636346266303137613465396239383361373334646133656530313333393762636138396364663037366566313366313436316534303761
So I just assumed everything is fine and that is the authorization token. But when I send this...
https://partner.uat.shopeemobile.com/api/v1/shop/auth_partner?id=(test_partner_id)&token=(authorization_token)&redirect=(test_redirect_URL)
... suddenly I get this
{
"error": "error_auth",
"msg": "Invalid token",
"request_id": "30a4b6b0074541bdd88260a33f155ca6"
}
In order to solve this, you have to understand that SHA256 is an Encryption hash function. Please research more on SHA256 on your specific language.
For this very specific case, your SHA256 token should be as below.
Before SHA256:
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
After SHA256:
2795f695f64bf017a4e9b983a734da3ee013397bca89cdf076ef13f1461e407a
The rest of your steps seems correct.
We have an instance of Identity Server 3 which has been used for some time with various clients, some using implicit flow, others using client credentials. We now have a new requirement to integrate an iOS native app with this identity provider. I understand these days implicit flow is not recommended and public facing apps should instead be using authorization code flow. Examples of such advice are here and here.
By my understanding, authorization code flow has a step whereby a received authorization code is exchanged for JWT tokens via some back channel by supplying it alongside a client ID and secret. However, with SPAs and native apps we don't have the luxury of storing secrets. The guidance I found here would suggest I can simply omit the secret from the connect/token request, but my testing so far doesn't confirm this. So I'm stuck. To demonstrate, I've set up a client on my local instance of IS3 to test with:
{
'clientId': 'test',
'flow': 'AuthorizationCode',
'name': 'test',
'redirectUris': [ 'http://localhost:8080/' ],
'scopes': ['openid','profile']
}
I then make the following GET request to my IdP:
[ID_PROVIDER]/connect/authorize?client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=openid%20profile&response_type=code
This lets me sign in and returns me to my test app running at http://localhost:8080 with my authorization code in the querystring.
I now try to exchange this code for JWT tokens by POSTing to [ID_PROVIDER]/connect/token with the following body: code=[AUTH_CODE]&grant_type=authorization_code&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080
But Identity Server rejects this with an HTTP 400 and invalid_client error. When I dig into its logs I see a ClientSecretValidator event with message "No client secret found". Which kind of makes sense based on my understanding outlined above, but given people are recommending using this flow for public-facing apps I must be misunderstanding something.
If anyone could clarify that'd be great, thanks.
You can't just omit the client secret. For your native case, I'd consider embedding the secret within the app. The authorize request will still have to validate the return_uri (custom URI scheme for your native app) and if that still feels insecure, you can also lean on Proof of possession (PoP) tokens (https://identityserver.github.io/Documentation/docsv2/pop/overview.html).
For a SPA app I would keep it implicit flow, I see no point in doing secrets there.
I am trying to validate a SAML response which is coming from Siteminder IDP from a third party. I have installed the certificate provided by them. When I call the ValidateToken method (System.IdentityModel.Tokens) to create claims, I get following error :
WIF10201: No valid key mapping found for
securityToken:'System.IdentityModel.Tokens.X509SecurityToken' and
issuer: 'issuer uri'
I dug in deep to find the error and its being thrown by method GetIssuerName (System.IdentityModel.Tokens).
Where is the problem? I googled for this issue but didn't find anything specific to my case. Does the SAML token from my client have a problem or there is something I am missing in implementation. I am fairly new to federated auth so please excuse any inaccuracy with the terminology used.
Gaurav
Ok found the solution but could't quite understand the readon behind it (complete noob, will update the answer when I know more).
Followed this approach of converting the SAML2 response to WSFed response, then on that new token I ran my code, now the error is gone.
http://blogs.msdn.com/b/bradleycotier/archive/2012/10/28/saml-2-0-tokens-and-wif-bridging-the-divide.aspx
Note : you still have to override the validate token method (which I had originally done) to avoid the following error :
“ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.”
Thanks.
You are probably missing a configuration that maps the issuer name (as specified inside the token) to the certificate (probably specified with a thumbprint). I guess you solve this with some configuration in your web.config. Have a look at p.e. Microsoft validating issuer name registry The page contains some sample configuration. Setting this up correctly depends entirely on your situation.
I wanted to make a note for future reference, since I also ran into this error but my resolution was different. I got the WIF10201 error in a custom MVC application that is using ADFS (3.0) claims-based authentication under Windows Server 2012. In the web.config of the MVC application, the thumbprint of the ADFS token signing key is recorded. It turns out, when the signing certificate is about to expire, ADFS creates a new key. The new key is marked "primary" and the old key is marked as "secondary" in the ADFS console (under AD FS/Service/Certificates). So in my web.config there was, of course, still the thumbprint of the old (secondary) key. As soon as I replaced it with the thumbprint of the new (primary) key, the error disappeared.