I would like to know if any of you have implemented "Sign in with Apple" under Azure AD B2C Environment.
I did not find clear information about how to implemented (Micrososft and Apple are not talking each other). I found trusted source at GitHub (https://github.com/azure-ad-b2c/samples/tree/master/policies/sign-in-with-apple), I followed the instruction, but did not work. Looks like there is some pieces of code missing or Apple/Microsoft/OpenId configuration has changed and this info is not included in the Post. I do not know.
My App was rejected by Apple because I am using additional identity providers (Social Networks) to sign in to my App, so Apple request to make their Identity Provider as an option ("Sign in with Apple").
Guideline 4.8 - Design - Sign in with Apple
We noticed that your app uses a third-party login service but does not offer Sign in with Apple.
Next Steps
To resolve this issue, please revise your app to offer Sign in with Apple as an equivalent login option.
Resources
To learn more, see the Sign in with Apple Overview.
So Far, I follow the instruction/recommendation but i can not make it works.
Today Azure AD only let OpenID as the only identity provider option for Apple.
Problem 1.
If I followed the GitHub Post (above), I got the following error:
Identity Provider Save Error
Cannot save Identity Provider: The issuer 'https://appleid.apple.com' found at the metadata endpoint.
So, I changed the issuer for my App Service Id, then Azure let me Save the provider, but it is not working as expected. (problem reported here: https://github.com/azure-ad-b2c/samples/issues/20)
Problem 2.
With the "new Issuer": My App ask for the AppleId (it looks working step 1), but nothing happens then (it did not create a user in the Azure AD, because nothing came to Azure) the App login remain in the AppleId.apple.com page forever (blank/white page)
Please, I will like to know if any of you has similar situation, and how you solved it.
Many thanks in advance
EDIT:
I found some important information about OpenID and Apple
Open Letter from the OpenID Foundation to Apple Regarding Sign In with Apple link
Apple Successfully Implements OpenID Connect with Sign In with Apple, link
'Sign in with Apple' better but not perfect, says OpenID Foundation head, link
Don't understand how Apple can force us to have "sign in with Apple" as an option if it not ready yet!
Updated on original thread as well. The issue is fixed now.
Sign in with Apple guide - the metadata endpoint is already in use by an identity provider
Related
I realize this is probably a "noob" question but I am trying to follow this guide to enable our users to sign in to Microsoft Azure AD using their email address instead of their UPN.
Some background: Our org uses a UPN scheme that is different from a users email address. Our UPN's follow the format abc12d#organization.com while user's email is firstname.last#organization.com. This enables us to have unique UPN's no matter how big our org scales. I am new to Azure AD but I've managed to integrate most of our 3rd party systems with Azure.
The problem: I mapped the user email field as the UPN for one of our services (Apple Business Manager) and now when a user tries to sign in to their Apple ID, it tries to sign them into Azure with firstname.last#organization.com instead of Azure UPN abc12d#organization.com. Because we have not enabled Microsoft's Sign-in using email as an alternate ID feature, the sign in window tries to sign them into an account that doesn't exist.
What I've tried: I know the simple solution would be to just change the mapping in Apple Business Manager to use the users true UPN from Azure but most of our sign-in's now use the users email so I really don't want to create confusion. I have tried to follow the guide mentioned above, which I assume is referring to using PowerShell in Azure and not your on-prem AD DS service (but it does not specify). Every time I attempt to follow the guide, I get an error message on step 3 in PowerShell that says Get-AzureADPolicy: The term 'Get-AzureADPolicy' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I have tried reading though various online forms but am yet to encounter anyone who is encountering this error for this specific use case. No other online documentation has helped me resolve the problem. In my mind, it is probably user error and limited experience with Azure and PowerShell cloud.
Any help would be greatly appreciated! I am happy to provide more information as needed.
Get-AzureADPolicy is under Azure Active Directory PowerShell 2.0-preview.
You need to install the preview release using:
Install-module AzureADPreview
Don't forget to import it:
Import-Module AzureADPreview
Note that you cannot install both the preview version and the GA version on the same computer at the same time.
Reference here. If it still doesn't work, running UnInstall-Module AzureAD before you install preview version may be helpful.
I am following this tutorial using the v4 SDK.
Add authentication to your bot via Azure Bot Service
Put simply, I click on the "Sign In" button from the OAuthPrompt card, a window pops up with the title "Sign In" and the screen is blank. This is using the bot service emulator.
I could be wrong but I feel like it's something to do with the content type.
application/vnd.microsoft.card.oauth
I wish I had more information to offer.
From the samples, I get the same outcome whether I use the BotAuthenticationMSGraph or AuthenticationBot example.
Thanks for the assistance. I've managed to progress but am not fully over the line yet. Maybe it's clearer for others, but for me, I followed what I thought were the instructions and did this:
Create Azure AD v2 Application (apps.dev.microsoft.com)
Create BOT Registration (Azure Portal)
... but in step 1. above, it automatically creates the app for you when you create the "Bot Channels Registration" so step 2 of creating the application is not required I created a second app and used that one in my settings and I think that's where I was going wrong.
Thanks for your help.
On another note, once the above was corrected and I removed myself from the company Wifi, it all came good. Network blocking issue!
I am trying to build a bot that will need a basic outlook login. I was watching this video
https://channel9.msdn.com/events/Build/2017/P4063?term=cortana%20skill
and the guy at 17:02 adds the following values for scopes and Authorization and Token URLs:
wl.basic wl.birthday
https://login.live.com/oauth20_authorize.srf
https://login.live.com/oauth20_token.srf
then I stumbled across Microsoft's documentation:
https://learn.microsoft.com/en-us/cortana/tutorials/bot-skills/bot-skill-auth
where it says that the values for the scopes and URLs are:
User.Read offline_access openid
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
The video is from May 10, 2017 (which was the BUILD 2017), and the article is from April 08, 2017. So which one is correct/deprecated? Also I tried to mix them and this is what the Login prompt looks like with the different combinations:
As you can see all four variations of scopes/urls produce totally different sign in UI?!?!?! (and the ones at the right column also look slightly broken) Which is the correct way?
UPDATE
Also, following the article I added a singin card to my bot with the URL described in the documentation:
var message = context.MakeMessage() as IMessageActivity;
message.Speak = "This is a Sign-in card";
message.Summary = "This is a Sign-in card";
message.Text = "Message Text";
message.Attachments = new List<Attachment>(){
new SigninCard("You need to authorize me", new List<CardAction>()
{
new CardAction()
{
Value = "https://login.microsoftonline.com/?redirect_uri=http%3a%2f%2fbing.com%2fagents%2foauth",
Type = "signin",
Title = "Connect"
}
}).ToAttachment()
};
await context.PostAsync(message);
and to my surprise clicking the sign in button, an entirely new login UI, resembling Office 365 pops up:
UPDATE 2 FRESH!!!:
https://twitter.com/chriscapossela/status/888029356504645632
This answer requires a little bit of history :)
Back in the day, in order to authenticate Microsoft users, you had to know if the user had an OrgId (used to log into Microsoft's business services) or MSA (used to log into non-business Microsoft services) identity. For reasons I won't digress on, it resulted in two oAuth endpoints:
https://login.live.com/... is/was the token endpoint for MSA-specific identities
https://login.windows.net/[AAD-TENANT-ID]/... is/was the token endpoint for OrgID-specific identities
Understandably, developers got very upset about this. To solve this issue, Microsoft created the v2 app model, which allows you to use one AuthN/Z endpoint for both account types. The v2 app model does a lot of black magic to abstract away differences in consent, scopes, endpoints, etc between MSA and OrgID, so you as a developer don't have to worry about it.
However - some of our APIs, especially those created pre-v2 endpoint, are geared for a specific account type. The Live APIs, which Nafis uses in the Build demo, IIRC don't play well with OrgID identities - if the user logged into the v2 endpoint with their OrgId account, you'd get non-ideal behavior since the access token would be for an OrgID account. To prevent this skill-breaking behavior, he uses the MSA endpoint (live.com) directly, preventing OrgID users from logging in to the skill at all.
You're seeing the different UX when mixing URLs because the v1 and v2 endpoints provide different login UX. The error message in the last image seems to indicate that you're using a MSA identity to log into a converged API. $5 says that's related to the fact that you're mixing v1 and v2 endpoints/scopes/etc, but it's hard to tell without looking at the exact API call.
The CSK docs use the v2 endpoint because most of our APIs (including the mail/Outlook APIs, which are now part of the Microsoft Graph) use it these days. When I'm writing code utilizing MSFT services (or when I'm writing documentation for the services ;)), I default to the v2 app model unless the API docs specifically mention v1 endpoints, like the live API docs do.
What steps are needed to customize the verification email sent by the Sign-up policy in Azure AD B2C? I have followed the MSDN faq and updated the Company branding with a banner image and a background color.
However the email which is sent is still the default email and my edits of the branding are not applied.
EDIT:
According to this page it seems as the Azure AD B2C need to be upgraded in order to use the company branding: Is this correct? And if so, how can i upgrade the tier to premium?
It seems odd since it was possible to edit the company branding without upgrading the tier.
It is now resolved.
This problem was caused by a bug in Azure.
After communication with the developer team they fixed it and the company branding started working.
To clarify: you don´t need to upgrade anything in order for company branding of the verification e-mail to work.
I am trying to add APNS connection in Azure Notification Hub with Token as authentication mode.
I have searched around but I am not able to find any guides anywhere to make this work.
Maybe someone has a link to a guide showing how to find the information needed?
I tried to create a "APNs Auth Key" in Apple developer console, but that gives me a .p8 file and the token inside that file does not seem to be accepted, so I guess I need to find the token somewhere else.
I hope someone have a link to a guide for setting this up and find the information needed.
Update (Apr 2018): #Krumelur reports in the comments that the blog article is out of date. Check out his suggestion on how to fix it to avoid getting errors.
Update (June 2017): There is now an official Microsoft post about Token-based (HTTP/2) Authentication for APNS.
Original answer (May 2017):
Token Based Authentication and HTTP/2 Example with APNS is a good step by step guide of how to get those values from your Apple Developer Account.
Key ID in Azure Portal is what APNS_KEY_ID is in the sample above
App Name in Azure Portal is your app name
App ID in Azure Portal is what TEAM_ID is in the sample above
Token in Azure Portal is the contents of the file referred to in APNS_AUTH_KEY variable in the sample above
Do not forget to keep track which keys and tokens are sandbox and which are production endpoint ones.
Looks like this is out of date. It is now looking for
Key ID
Bundle ID
Team ID
Token
Everything is described now in the documentation here.