I'm trying to make App Insights work so I can debug my policies, using this:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom
And based on this project:
https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts
Made the proper modifications:
<TrustFrameworkPolicy
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
PolicySchemaVersion="0.3.0.0"
TenantId="B2CPruebaProteccion.onmicrosoft.com"
PolicyId="B2C_1A_PasswordReset"
PublicPolicyUri="http://B2CPruebaProteccion.onmicrosoft.com/B2C_1A_PasswordReset
UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights">
<BasePolicy>
<TenantId>B2CPruebaProteccion.onmicrosoft.com</TenantId>
<PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
</BasePolicy>
<RelyingParty>
<DefaultUserJourney ReferenceId="PasswordReset" />
<UserJourneyBehaviors>
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="00000000-0000-0000-0000-000000000000" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
...
</TrustFrameworkPolicy>
My data is not showing up in App Insights. How can I validate/repair this error?
You must also add the DeploymentMode="Development" attribute to the TrustFrameworkPolicy element.
For example:
<TrustFrameworkPolicy
PolicySchemaVersion="0.3.0.0"
TenantId="contoso.onmicrosoft.com"
PolicyId="B2C_1A_sign_up_sign_in"
PublicPolicyUri="http://contoso.onmicrosoft.com"
DeploymentMode="Development"
UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights"
xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</TrustFrameworkPolicy>
Dont use app insights with custom policies unless your happy for user data to be pushed to app insights
The journey recorder endpoint - urn:journeyrecorder:applicationinsights scrapes everything and chucks it to app insights, all usernames, password exist in App insights in clear text.
The best bet is to create a function app that accepts any a form body and pass it any claimsthat you want to send from B2C and then call it with the RESTFul provider in a technical provider
This way you can stop sensitive data going to App insights
They are also very clear not to use the journey recorder on production envs as it slows production down
Related
I set up a SAML Provider for Azure B2C (Single Sign On). The IDP is happy and sends a SAML Assertion back, but Azure B2C complains.
It looks like Azure B2C cannot process the SAML Answer. The Error Message extracted via AppInsights is simple "The service provider is not a valid audience of the assertion".
The URLs seem to fit, but im not sure if the AudienceRestriction should point to the base policy or maybe the sign-in policy, as teh metadata can only be accessed via the SIGN-UP Policy as part of the URL and not the BASE:
"https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_SIGNUP_SIGNIN/samlp/metadata?idptp={IDP-NAME}-SAML2"
Configuration (updated according to the comments of this question).
Configuration
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="https://{IDP-URL}/saml/2.0/idp/"
entityID="https://{IDP-URL}/saml/2.0/idp/"
validUntil="2099-12-31T23:59:59Z">
<SPSSODescriptor
AuthnRequestsSigned="false"
WantAssertionsSigned="false"
ResponsesSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<AssertionConsumerService
index="0"
isDefault="true"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
</SPSSODescriptor>
<IDPSSODescriptor
WantAuthnRequestsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://{IDP-URL}/saml/2.0/idp/" />
</IDPSSODescriptor>
</EntityDescriptor>
SAML Response
<saml2p:Response Destination="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer"
ID="Response_6793aae6a9cc629a6be69a270731961695dad50e"
InResponseTo="_719e3407-dbad-4761-8e8a-7e7272b2a67b"
IssueInstant="2022-08-17T08:34:29.112Z"
Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://{IDP-URL}/saml/2.0/idp/</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2:Assertion ID="Assertion_16dc5f9b7c67ed241c79436c20296a2fd514ea87"
IssueInstant="2022-08-17T08:34:29.111Z"
Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<saml2:Issuer>https://{IDP-URL}/saml/2.0/idp/</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#Assertion_16dc5f9b7c67ed241c79436c20296a2fd514ea87">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="xs"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>/4OAX07/scGvFyDCT3BBzlHJQ7q65Ak0uGlTvE0z904=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>{removed}</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>{removed}</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">71747</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_719e3407-dbad-4761-8e8a-7e7272b2a67b"
NotOnOrAfter="2022-08-17T08:34:39.112Z"
Recipient="https://{my-tenant-name}/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer"
/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2022-08-17T08:34:29.111Z"
NotOnOrAfter="2022-08-17T08:34:59.111Z"
>
<saml2:AudienceRestriction>
<saml2:Audience>https://{my-tenant-name}/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2022-08-17T08:34:29.111Z"
SessionNotOnOrAfter="2022-08-17T10:34:29.111Z"
>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
My SAML METADATA
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_7865bef4-f0d2-4062-9e58-a145e1beb91f" entityID="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_7865bef4-f0d2-4062-9e58-a145e1beb91f">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="saml samlp xenc xs"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>bSqD69uUzX0swY6hAKkzLEaWJeMyV2UIoyFBTxLhHi0=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>AiyK11or3hAGSnHADidHKp2XCcH0amBaU8xA6xQrxgKNZBqaKFF0rdbiRdVp4YFbqlQeCruYAEbT1JnAAwRyKLn6IZOJIP7iA3PeSr8bguus58+LGmb30YsYcbpAMxLjhQbmAu1t25v4huaOViZQwNAafkdjKAyhJRa7P8ihEBbl4CUQjYJ0eIASxWZuD6j1tg4afMv9GH809lFGl7KRER8oUp9P6VF5xdJbavpX623eRZRAeqV++CBXKTrFUnMOHrp1eI68IaobKOx/xkN59FX7SabdqpIVE+L9rnPtYYwG0LLpqmAOaSZEhmGKp2y27OA1ZxJZittwFMTmWmtoqA==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>{removed}</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>{removed}</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_signup_signin/samlp/sso/logout" ResponseLocation="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_signup_signin/samlp/sso/logout/response"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>
</EntityDescriptor>
Please check below points:
Subject contains a NameID element, which represents the authenticated user. The NameID value is a targeted identifier that is directed only to the service provider that is the audience for the token. It is persistent - it can be revoked, but is never reassigned.
nameidpolicys element requests a particular name ID format in the response
ex:
<NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
The Format attribute can have only one of the following values;
Persistent, emailAddress, unspecified, transient
For urn:oasis:names:tc:SAML:2.0:nameid-format:persistent : Azure
Active Directory issues the NameID claim as a pairwise identifier.
For urn:oasis:names:tc:SAML:2.0:nameid-format:transient: Azure Active
Directory issues the NameID claim as a randomly generated value that
is unique to the current SSO operation. This means that the value is
temporary and cannot be used to identify the authenticating user.
But as seen from the configuration that you provided , it seems to be transient:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
And response has it persistent. Please check with that.
Audience in audience restriction contains a URI that identifies an intended audience. Azure AD sets the value of this element to the value of Issuer element of the AuthnRequest that initiated the sign- on. Please check and Configure Azure Active Directory B2C as a SAML IdP to your applications | Microsoft Docs
Conditions element specifies conditions that define the acceptable use of SAML assertions.Please check the allowed audience is valid.
References:
using-azure-ad-b2c-as-a-saml-idp-with-the-sp-initiated-flow(medium.com)
audience restriction and proxy restriction-saml-core-2.0-os.pdf
I have this kind of internal errors inside our Production B2C environment.
Our Insights in the Relaying Party:
And our AppInsights-Common:
Exception after 2 or 3 409 business validation exceptions:
Any idea how to fix this?
Thanks.
Please check the following:
When you create an instance of Application Insights in your subscription for required resources, make sure to record the INSTRUMENTATION KEY .
and ensure the recorded instrumentation key is provided and developer mode to false in the metadata of technical profile (Don't enable developer mode in production environments.)
<TechnicalProfile Id="AppInsights-Common">
<DisplayName>Application Insights</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.Insights.AzureApplicationInsightsProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<!-- The ApplicationInsights instrumentation key, which you use for logging the events -->
<Item Key="InstrumentationKey">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</Item>
<Item Key="DeveloperMode">false</Item>
<Item Key="DisableTelemetry ">false</Item>
</Metadata>
<InputClaims>
....
</InputClaim Claims>
Reference: Track user behavior by using Application Insights - Azure AD B2C | Microsoft Docs
or
Make sure to replace {Your Application Insights Key} with the Application Insights Instrumentation Key that you recorded earlier in the user journey.
ex:
<UserJourneyBehaviors>
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
</UserJourneyBehaviors>
When using in production environments,i.e; in the configuration in TrustFrameworkPolicy
Please make sure to set the DeploymentMode attribute to Production(not developer)
<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0"
.....
DeploymentMode="Production"
UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights">
And change DeveloperMode="false" in userjourney:
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="false" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
Please check this doc to Troubleshoot custom policies with Application Insights - Azure AD B2C | Microsoft Docs .
And please note that these detailed logs are collected only when the
policy is placed in DEVELOPER MODE.
logs may take a little or some time to populate under app insights.
Also sometimes the order of userjourney may affect the output, try
changing it to other step or order .
I am using Azure B2C custom policy for passwordless signin following this sample.
The <BuildingBlocks> section has the <ClaimsTransformations>.....</ClaimsTransformations> which defines random password generation. To customize the UI for my login screens I have also added <ContentDefinitions> .... </ContentDefinitions> inside <BuildingBlocks> section.
Now I am getting a validation error when trying to upload the TrustFrameworkExtensions_passwordless_only.xml file saying that the ---> element <BuildingBlocks> has invalid child element <ClaimsTransformations>. List of possible elements expected: Localisation, DisplayControls.
This is strange because in the reference schema ClaimsTransformations is also a valid element. Not idea why I am getting this error. Can anyone please help me with this issue?
According to official AD B2C custom policy documentation on BuildingBlocks:
The BuildingBlocks element contains the following elements that must be specified in the order defined:
<BuildingBlocks>
<ClaimsSchema>
...
</ClaimsSchema>
<Predicates>
...
</Predicates>
<PredicateValidations>
...
</PredicateValidations>
<ClaimsTransformations>
...
</ClaimsTransformations>
<ContentDefinitions>
...
</ContentDefinitions>
<Localization>
...
</Localization>
<DisplayControls>
...
</DisplayControls>
</BuildingBlocks>
So the order matters and you need to place ContentDefinitions block after ClaimsTransformations block.
What do I need
In my application I have a following schema
users (id(PK), username, email(unique), password, etc)
devices (id(PK), device_id, status, user_id)
Relation
user HAS ONE device
The application needs to support basic authentication in two variations.
Variation one: Normal, email as username and password. This approach will be used by the admin console. The admin console just like an webapp.
Variation two: email as username, device id as password. This approach will be used by mobile application. During the authentication process from device, it will pass the device id as password. Since a user will have only device at a time, the authentication process will match the device id and email to identify the user.
What I tried?
I have basically followed symfony tutorial on api key based authentication for the second variation and http-basic for the first. Please find my security.xml below.
Here, I need the firewall setup to pass when any of the underlying authentication mechanism passes. For instance, in case of web authentication, only http-basic will pass, in case of device login only simple-preauth will pass.
security.xml
<srv:container xmlns="... ...">
<config>
<firewall name="resource" pattern="^/" stateless="true">
<http-basic realm="Webservice" />
<simple-preauth authenticator="device_authenticator" />
</firewall>
<provider name="administrators">
<entity class="AppBundle\Entity\User" property="email"/>
</provider>
<provider name="device_id_user_provider" id="device_id_user_provider" />
<encoder class="AppBundle\Entity\User" algorithm="bcrypt" cost="12"/>
</config>
</srv:container>
services.xml
<container xmlns="... ...">
<services>
<service id="device_id_user_provider"
class="AppBundle\Security\DeviceIdUserProvider">
<argument type="service" id="doctrine.orm.entity_manager" />
</service>
<service id="device_authenticator" class="AppBundle\Security\DeviceAuthenticator">
<argument type="service" id="device_id_user_provider" />
</service>
</services>
</container>
My problem
For every request the firewall tries to pass both of the authentication mechanisms. Hence its always responding with 401.
Did I set this up in a wrong way?
Or a firewall MUST pass all of its underlying auth mechanisms?
Or this is happening only because of using preauthentication?
Any recommended approach to achieve this?
When I send a SOAP request to DocuSign it is showing an error: This Account lacks sufficient permissions. In-Session permission required when specifying a captive recipient.
Full response XML is:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soap:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/addressing/fault</wsa:Action>
<wsa:MessageID>urn:uuid:9f406870-dc55-441d-b5ff-8317166636b9</wsa:MessageID>
<wsa:RelatesTo>urn:uuid:b572d1a4-b8b5-4254-8f1d-7fd46fb593f1</wsa:RelatesTo>
<wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsse:Security>
<wsu:Timestamp wsu:Id="Timestamp-656764ea-c0f0-4074-88b1-dbffae666a83">
<wsu:Created>2013-08-01T18:00:46Z</wsu:Created>
<wsu:Expires>2013-08-01T18:05:46Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>This Account lacks sufficient permissions. In-Session permission required when specifying a captive recipient.</faultstring>
<faultactor>https://www.docusign.net/api/3.0/dsapi.asmx</faultactor>
<detail>
<ErrorCode xmlns="missing in Web.Config">111</ErrorCode>
<ErrorReason xmlns="missing in Web.Config">This Account lacks sufficient permissions.</ErrorReason>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
A request we send is:
User-Agent: SFDC-Callout/28.0
X-DocuSign-Authentication: <DocuSignCredentials><Username>There is a user name</Username><Password>There is a password</Password><IntegratorKey>There is an integrator key</IntegratorKey></DocuSignCredentials>
Accept: text/xml
Content-Type: text/xml
charset: UTF-8
SOAPAction: "http://www.docusign.net/API/3.0/CreateAndSendEnvelope"
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header />
<env:Body>
<CreateAndSendEnvelope xmlns="http://www.docusign.net/API/3.0">
<Envelope>
<AccountId>There is an accountId</AccountId>
<Documents>
<Document>
<ID>1</ID>
<Name>Bayfront - Smoke free environment form - Antony.pdf</Name>
<PDFBytes>There is an encoded body</PDFBytes>
<FileExtension>pdf</FileExtension>
</Document>
</Documents>
<Recipients>
<Recipient>
<ID>1</ID>
<UserName>mikhail</UserName>
<Email>mikhail.ivanov#targetrecruit.net</Email>
<Type>Signer</Type>
<AccessCode xsi:nil="true" />
<RequireIDLookup>false</RequireIDLookup>
<CaptiveInfo>
<ClientUserId>1</ClientUserId>
</CaptiveInfo>
<RoutingOrder>1</RoutingOrder>
<RoleName>Signer</RoleName>
</Recipient>
</Recipients>
<Tabs />
<Subject>Please Sign this Document: </Subject>
<EmailBlurb>This is my new eSignature service, it allows me to get your signoff without having to fax, scan, retype, refile and wait forever</EmailBlurb>
<CustomFields>
<CustomField>
<Name>DSFSSourceObjectId</Name>
<Show>false</Show>
<Required>false</Required>
<Value>Credential ID</Value>
</CustomField>
</CustomFields>
</Envelope>
</CreateAndSendEnvelope>
</env:Body>
</env:Envelope>
What can be the reason? How should I fix it?
DocuSign developer sandboxes have this enabled by default so you can test Embedded Signing (and sending, etc) before going live.
In terms of live production accounts- not all accounts have embedding enabled so ensure you have purchased an account that has it. If you are getting this error in production you most likely need to upgrade.