I added and configured an OpenID Connect Identity Provider.
I set the return URL in the provider correctly.
I'm using the "Sign up and Sign in" user flow -- not a custom policy.
Running through the user flow, I ultimately get redirected to my application .../MicrosoftIdentity/Account/Error (or if I set return url to jwt.ms, I get the same error) with the page indicating the error
AADB2C90238: The provided token does not contain a valid issuer
How can I even see the issuer in the token? (It's all handled inside AD B2C service).
I can see what's listed in the provider's .../.well-known/openid-configuration endpoint. I guess that's what's not matching in the token. I've seen suggestions of using Application Insights Logs to view the token -- but, apparently, that can only be done with custom policies.
Is there another way to tell AD B2C not to validate the issuer? Or is another way to handle this issue?
I tried to reproduce the same in my environment.
Open Id configuration is like below:
Where the metadata url is https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
Authorization request looks like below:
https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_newSignupSignin&client_id=xxxxx5&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid&response_type=id_token&prompt=login
I received the same error :
With redirect uri: https://jwt.ms
Error: invalid_request
AADB2C90238: The provided token does not contain a valid issuer. Please provide another token and try again.
With redirect uri: https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/authresp
So here the redirect Uris are correct and need to correct the metadata url :
Created an OpenId provider with meta data url having tenantId instead of organizations .
https://login.microsoftonline.com/<tenantId>/v2.0/.well-known/openid-configuration
Run the user flow with this Identity provider
Could login successfully and get the access token with endpoint
Note: make sure it has the policy included:
I have p=B2C_1_newSignupSignin
https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_newSignupSignin&client_id=1xxxxe2a5&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid&response_type=id_token&prompt=login
Here the issuer is of V2 endpoint "iss": "https://kavyasarabojub2c.b2clogin.com/<tenantId>/v2.0/"
Reference : Web sign in with OpenID Connect - Azure Active Directory B2C | Microsoft Learn
Edit:
Setting up a custom policy in Azure AD B2C to connect to a SAML Identity Provider. This requires a SAML metadata endpoint to get the SSO URL and other information.
As per Microsoft documentation the End point link is :
https://[my-tenant].b2clogin.com/te/[my-tenant].onmicrosoft.com/[my-policy]/samlp/metadata?idptp=[my-technical-profile]
I tried this way but I am constantly getting the same error :
Unable to return metadata for the policy 'B2C_1A_TrustFrameworkExtention' in tenant 'Mytenant.onmicrosoft.com'.
Is this error due to some fault in my policies ?
Typo?
The usual name is:
TrustFrameworkExtensions
You have:
TrustFrameworkExtention
I am getting below error while connecting to Azure Active Directory
"AADSTS90009: Application 'xxxxxxxxxxxxxxxxx' is requesting a token for itself. This scenario is supported only if resource is specified using the GUID based App Identifier.
If you want to use web application to call web API, please refer to the sample. The detailed steps.
Register your Web API application in Azure Portal. For more details, please refer to the document.
Register your Web app application in Azure Portal
Grant permission.(add you web API application in you web app application)
a. select you web application
b. set permissions.
Get access token
Method : POST
URL : https://login.microsoftonline.com/ [Directory ID]/oauth2/token
Headers
Cache-Control : no-cache
Content-Type : application/x-www-form-urlencoded
Body
grant_type : password
resource : Your App ID URI
client_id : [application id]
client_secret : [key value]
username : [account name]
password : [Password]
This error is saying that the field you provided in the resource parameter is requesting tokens for itself.
Alternatively, you can provide an app ID URI of a web API you've registered or another resource with scopes to get tokens for that resource (Microsoft Graph, Office API, etc).
The error information indicates that you are using Azure AD application url as resource.
As qwe mentioned that you need to use the WebApp API(Not Azure AD application) you wanted to access as resource. For more information please refer to this link.
POST https://login.microsoftonline.com/{tenantId}/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id={clientId}&client_secret={secret key}=&resource={resourceaddress}
Note： If we want to use the OAuth 2 grant type: password, we need to registry Azure AD native application. For more information please refer to another SO thread.
Our client has an Azure AD containing all users in his company located in multiple locations around the world. He would like his users to be able to sign into our SP app using their Microsoft Accounts which are on Azure AD.
Obviously, since Azure AD uses SAML 2.0, and SharePoint uses Ws-Fed (which is similar to SAML 1.1), we need to convert these claims from 2.0 to Ws-Fed (or SAML 1.1).
This used to be done using Azure's Azure Control Services, which is going to be deprecated at the end of the year (2018), so there's no point in developing a solution that uses it.
As such, we found a number of guides here and here which detail how a Claims Provider Trust can be created between Azure AD and ADFS, and a Relying Party Trust be set up between AD FS and SharePoint.
In theory this works in the following way:
User logs into his Microsoft Account which is on the Azure AD, and the SAML 2.0 token with claims is sent from Azure AD to AD FS
All claims are passed to AD FS, since we configured our rules in this way (as instructed here)
AD FS converts these from SAML 2.0 to Ws-Fed (or SAML 1.1)
AD FS maps the necessary claims to the UPN (as instructed here) and sends the result to SharePoint
We seem to be encountering an issue in the conversion step.
We have debugged the process using Fiddler, to see requests to and from the AD FS server. Azure AD claims are successfully sent to AD FS, but an error is encountered when AD FS is issue new claims (supposedly in Ws-Fed or SAML 1.1).
The following is the stack trace from AD FS:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, UInt32 lifetime, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
We've also done internal testing, whereby we logged in to the SharePoint site using the the local AD, in order to make sure that the setup between AD FS and SharePoint is correct. This worked as expected, and SharePoint received the claims as configured in step 4.
Any help with the "conversion" process from SAML 2.0 to Ws-Fed (or SAML 1.1) would be greatly appreciated.
Help me Obi-Wan Kenobi, you're my only hope!
Set AD FS' PreventTokenReplays param to false
In our case, this is what had us stuck for days. There was no mention of this anywhere that we read, and we only found out about it after going to the AD FS server's event viewer and going through the logs.
Open up PowerShell, and add the AD FS snapin using the following:
Add-PSSnapin Microsoft.Adfs.PowerShell
Then, get your AD FS properties, using the following:
Get-adfsproperties
Check the value for the PreventTokenReplays param. If it's set to false, you should be good. If it's set to true, then flip it to false using the following command:
Set-adfsproperties -PreventTokenReplays $false
Now, you'll need to restart your AD FS service. Just go to services.msc, find AD FS 2.0 Windows Service, right click it, and hit restart.
Configuration Overview
Create a new Azure AD tenant and namespace.
Add a WS-Federation identity provider.
Add SharePoint as a relying party application.
Create a rule group for claims-based authentication.
Configure the X.509 certificate.
Create a claim mapping.
Configure SharePoint for the new identity provider.
Set the permissions.
Verify the new provider
You can follow this blog for step by step process
https://www.sharepointcollabs.com/2017/03/using-microsoft-azure-active-directory.html
I configured azure AD as an identity provider for my organization's application
whenever i try to access the application its redirecting the request to azure login. But I am getting a bad request error and its showing the below message
The SP name qualifier 'abc.xxxx.com' is not valid.
I am not sure if i have done something wrong.
Below is my configuration
SIGN ON URL
https://abc.xxxx.com/myapp/saml/ssoRequest?ticket=kcflmlmnpgg
ISSUER URL
https://abc.xxxx.com
REPLY URL
https://abc.xxxx.com/myapp/ssoResponse
The problem was when i was submitting the SAML request I was not prepending the 'http://' in the service provider name