I created in laravel a scim route with total return results 0 and I got the secret certificate in application registration and generate certificates and secrets but it doesn't work.
SystemForCrossDomainIdentityManagementCredentialValidationUnavailable Details: We received this unexpected response from your application: An HTTP/404 Not Found response was returned rather than the expected HTTP/200 OK response. To address this issue, ensure that the tenant URL is correct. The tenant URL is usually in a format like: https://<>/scim. If this does not resolve the issue, contact the application developer to ensure their SCIM endpoint conforms with the protocol
as is returning my route:
return response()->json(['schemas'=>["urn:ietf:params:scim:api:messages:2.0:ListResponse"],'totalResults' => 0, "Resources" => [],"startIndex" => 1,"itemsPerPage" => 20]);
The AAD provisioning service starts off by sending a few GET requests looking for non-existent resources - i.e.: GET /Users?userName eq "469787bf-b179-4ef9-bc60-ee07cc78fd47". The expected response is a 200/OK with ListResponse type response with totalResults of 0.
The message you're getting back indicates that one of these test API calls is getting a 404 rather than a 200. This could be because the URL is incorrect, or the SCIM implementation is noncompliant and is returning a 404 for a query that returns zero results.
Related
I have been using MSAL in my React app for some time with success. One of the tokens that my app requests is for scope 'https://management.core.windows.net/user_impersonation'. I have a nodeJS server that I want to push that token acquisition to so I installed msal-node (1.12.1) and tried using the OBO flow:
const pca = new msal.ConfidentialClientApplication({
auth: {
clientId: settings.config.azure.clientId,
clientSecret: settings.config.azure.clientSecret,
authority: "https://login.microsoftonline.com/<tenantid>",
knownAuthorities: ["https://login.microsoftonline.com/<tenantid>"],
}
});
const request = {
scopes: ['https://management.core.windows.net//user_impersonation'],
oboAssertion: <token_extracted_from_auth_header>
}
const response = await pca.acquireTokenOnBehalfOf(request);
return response.accessToken;
However the above code results in the following error:
ClientAuthError: endpoints_resolution_error: Error: could not resolve endpoints. Please check network and try again. Detail: ClientAuthError: openid_config_error: Could not retrieve endpoints. Check your authority and verify the .well-known/openid-configuration endpoint returns the required endpoints. Attempted to retrieve endpoints from: https://login.microsoftonline.com/tenantid/v2.0/.well-known/openid-configuration
If I visit the URL it complains about I do get back some metadata so not really sure why it is failing.
Anybody have a suggestion?
Also in regards to OBO flow:
For my nodeJS app I have added that permission to the required API list
I presume the oboAssertion field is the token that is passed to my nodeJS app by the client? I simply extracted it from the Auth header
The actual error message there means that the URL that we are trying to contact is wrong. And it is wrong https://login.microsoftonline.com/tenantid/v2.0/.well-known/openid-configuration returns an error.
A coorrect one is: https://login.microsoftonline.com/19d5f71f-6c9a-4e7f-b629-2b0c38f2b167/v2.0/.well-known/openid-configuration
Notice how I used an actual teanant_id there. You can get yours from the Azure Portal - it's the "directory id"
If your web api is single tenant, i.e. it is only meant for the people in 1 organization, then the is the tenant id of that organization. It is also known as "directory id". You get it from the Azure Portal.
However, if your api is multi-tenant, i.e. it's a bit more complicated, and the "correct" answer is to use the tenant id of the incoming assertion. It's the tid claim in it.
I have a protected service, but I need to create links for sharing purpose. So I came over this feature:
new ApiKeyAuthProvider(AppSettings) {
AllowInHttpParams=true
},
I'm calling the service, getting the API directly from the ApiKey table, and in the debug console I can even see the SQL, which is correct (select where id, and id is my api key) and matches an active user, but still I'm getting a 403 from ServiceStack.
The apikey query param is used. Https is used (with valid CA signed cert).
403 Forbidden indicates Authentication was successful (otherwise would return 401 unauthorized) but the authenticated user does not have access to the resource, e.g. they don't have the required roles or permissions.
I try to use node-openid-client to get access code from wso2 identity server.
How can i send authentication credentials?
'use strict';
const { Issuer } = require('openid-client');
Issuer.discover('https://localhost:9443/oauth2/oidcdiscovery') // => Promise
.then(function (wso2Issuer) {
console.log('Discovered wso2Issuer %s', wso2Issuer);
});
My result:
node:23516) UnhandledPromiseRejectionWarning: AggregateError:
OPError: expected 200 OK, got: 401 Unauthorized
I am assuming this Issuer.discover method is trying to access a /.well-known endpoint.
The reason for you getting 401 Unauthorized is because in WSO2 IS 5.7.0 this endpoint is secured by default.
There are two solutions to your problem
Send the Authorization: Basic header with base64 encoded user credentials. i.e.: Authorization: Basic base64encoded(username:password)
Make the endpoint unsecure.
Since this is a discovery endpoint I would say to go with option 2.
You can make this endpoint unsecure by doing the following; Open the
identity.xml file inside <IS-HOME>/repository/conf/identity/ and
locate the <ResourceAccessControl> tag.
Inside that tag you can find a resource matching <Resource context="(.*)/.well-known(.*)" secured="true" http-method="all"/> set secured to false.
i.e.: <Resource context="(.*)/.well-known(.*)" secured="false" http-method="all"/>
You will need to restart the server for the configuration change to take effect.
Through experimentation with the Azure REST API, I have found cases in which a response for an unauthorized request has a 200 code with an empty response:
{
"value": []
}
Specifically, I've observed two scenarios, both occurring using a client application authenticated with a valid bearer token:
If the client has no roles assigned, requests to any API requiring explicit access return a 403 error code as expected.
If the client has a role assigned that does not authorize the endpoint being accessed, a 200 response with an empty payload is returned.
Regarding the second scenario, I would expect that this request would still return a 403 error code since the access is unauthorized given that the assigned role(s).
Is this expected behavior?
Concretely, I've tested the second scenario above by assigning the Network Contributor role to an application and attempting various GET operations outside of the actions permitted. For all unauthorized accesses, an empty value property is returned. When I test the same endpoints with a Reader role, the value property is populated.
This is the answer I received from Microsoft on the subject:
The behavior you are seeing is expected for APIs that return a
collection of resources, the reason for this is that the permissions
are evaluated per resource, so that only the resources where you have
permissions are returned.
This is the way we process the request:
We verify the permissions of the user making the call, if there are no permissions, an Unauthorized error is returned.
The API call is then sent to the resource provider to handle, in this case, we ask for the full collection of resources.
The results returned from the resource providers are then filtered based on the permissions the user has.
The filtered results are returned to the user. (If everything was filtered out, then the response will be empty).
I understand how this may be confusing, in this case, the list API is
not restricted for the user, we restrict the results returned in the
response, that's why a 200 OK with an empty array is the correct
response to the scenario you have shared with us.
After developing in the sandbox, we got our api key approved and promoted to a live account.
Since then we've been getting the following response -
response: {
"errorCode": "ACCOUNT_LACKS_PERMISSIONS",
"message": "This Account lacks sufficient permissions."
}
http code: 401
exeucted at: 2017-05-17 15:03:59
Based on my research and according to ACCOUNT_LACKS_PERMISSIONS error when creating envelope
A setting needs to be switched on the backend at Docusign. The user mentions -
"They changed a setting called In Session to Enabled in API section near limiter that only the account manager or tier 2 support can change. All is well."
The account ID is 30953035
API username bcbffa28-a316-473e-b2b7-48d964d909a7
The API request is below. This was working just fine under a Demo account. I've even upgraded to the Intermediate API in the hopes that it will resolve my issues but no dice.
Support says that I need to post here...
This is caused by a bad account baseUrl that's being used in the request. When your integration performs authentication for a given user, if you are using Legacy auth (X-DocuSign-Authentication header) then you need to point to the following /login_information endpoint for the live system:
https://www.docusign.net/restapi/v2/login_information
When you get the response you then need to parse the baseUrl value that was returned and use that sub-domain for subsequent API requests. (Note that there are multiple sub-domains in the live system such as NA1, NA2, EU, etc)
The baseUrl that's returned will look something like:
https://na2.docusign.net/restapi/v2/accounts/12345/envelopes
Make sure you configure your code to read this sub-domain and use in subsequent requests, otherwise you if you simply use www for instance you will not be hitting the correct account endpoint and you'll receive the "Account lacks permissions" error you're receiving.
Ergin's answer seems to work; however, he does not state which part of the baseUrl to keep after parsing. In his example the baseUrl = "https://na2.docusign.net/restapi/v2/accounts/12345/envelopes" In all subsequent calls after authApi.Login(); use "https://na2.docusign.net/restapi" as the URL and that should eliminate the error message.