I have no Access Control Service (ACS) installed, but I've seen on some online video demo that Salesforce is not in the list of available pre-installed identity providers. Salesforce can be configured as IdP (standard SAML 2.0 is used). Can I setup ACS so that I can use Salesforce as identity provider? Thanks
I haven't personally used a SAML 2.0 token provider, but it's official description says that ACS supports SAML 2.0 tokens. A list of supported protocols are OAuth 2.0, WS-Trust, and WS-Federation (as by official statement).
Also, there is no currently automated (with user interface) way to add identity providers that are out of predefined in the ACS. You can however use the ACS cmdLets to manually add IPs that have a supported protocol. Here is a Vittorio's blog that shows how to add an openID provider.
If you can configure the SalesFores as IdP with the use of SAML 2.0 tokens, you just to identify the protocol - is it OAuth, is it WS-Trust of WS-Federation, and execute a PowerShell command which would look something like this:
PS:\>Add-IdentityProvider –Namespace "myacsnamespace" –ManagementKey "XXXXXXXX" -Type "Manual" -Name "SalesForce" -Protocol OAuth –SignInAddress "http://www.your_salesforce_site.com/sign-in-url"
The list of supported protocols for this command is: WsFederation, OAuth, OpenId, WsTrust. So the SalesForce IdP configuration must use some of those protocols with SAML 2.0 tokens and it must work. I think it's the OAuth as by this wiki.
Hope this helps!
Related
On this Microsoft documentation on Azure AD B2C, I read
OpenID Connect is recommended if you're building a web application that's hosted on a server and accessed through a browser. If you want to add identity management to your mobile or desktop applications using Azure AD B2C, you should use OAuth 2.0 rather than OpenID Connect.
What are the roles of OpenID Connect and OAuth 2.0 in Azure AD B2C and what features they separately support?
The question is not quite correct. On the same page you can read
OpenID Connect extends the OAuth 2.0 authorization protocol for use as
an authentication protocol. This authentication protocol allows you to
perform single sign-on. It introduces the concept of an ID token,
which allows the client to verify the identity of the user and obtain
basic profile information about the user.
OpenID Connect (OIDC) is an extension or superset standard/RFC for OAuth 2.0. Both protocols define authentication flows, while OAuth2 is a bit generic, a general framework, that gives a lot of freedom of choice, OIDC specifies important aspects in detail. OIDC adds id_token in JWT format in addition to access token, flows like Hybrid flow, token introspection endpoints etc to OAuth2.
Usually OAuth2 comes together with OIDC. If you want to know difference in detail then there are RFCs for OIDC and OAuth2
So your questions is about protocol difference, you can find a lot of information in addition to RFCs. Here is IMO good article link.
In short:
OAuth2
access token use but not format specified
Authorization Code Grant
Implicit Grant
Resource Owner Password Credential Grant
Client Credential Grant
OIDC
extension of access token by id_token use. id_token in JWT format
token endpoints, self issued token, offline access
Authorization Code Flow (extension to Authorization Code Grant)
Implicit Flow (extension Authorization Code Grant)
Hybrid Flow
B2C is focused on use from client application side from consumer applications. When you will be creating IdP provider Azure B2C support already existing social providers (Facebook, Microsoft etc), which in fact are OIDC with proprietary extensions, or custom OIDC IdP provider. In terms of API and authentication flows, and it is very typical for any IdP provider, it supports both, so you can use HTTP API for OAuth2 or OIDC, and OIDC is recommended.
As a service provider, I need to integrate third party oAuth providers beyond what is currently available in the portal. How can I do that? Any pointers will be helpful. If it is not supported, is it in the product road map?
Currently, you have to create custom policies to integrate with other OpenID Connect and OAuth identity providers, such as Azure AD and GitHub.
The "Add support for a generic OpenID Connect Identity Provider" feedback item indicates development has been started for the built-in support of any OpenID Connect or OAuth provider.
I successfully implemented Azure Active Directory for user management/authentication/login in a web app, following this example:
Azure Sample AAD with Flask
I decided to try Azure Active Directory B2C because of its integration for the various social apps. However, I could not get the flask app to work using OAuth 2.0, since Azure AD B2C does not seem to be compatible with OAuth 2.0. I found some documentation that states Azure AD B2C requires Open ID Connect.
Could you please confirm whether Azure Active Directory B2C requires Open ID Connect, or whether it works with OAuth 2.0 as well?
Thanks
It is worth to not that Azure Active Directory B2C (AAD B2C) supports both OpenID Connect and OAuth 2.0 in that it uses these two protocols to exchange information and secure tokens. However, AAD B2C "extends" these protocols by introducing Policies to handle the user experience for Sign-up, Sign-in and general account management.
What does this mean? First of, it means that you cannot create your own sign-up/sign-in experience, you are restricted to redirecting the user to the right policy (which you to some extent can customize). You cannot create your own sign-up/-in UI for this and you are restricted to styling/branding the provided web-based UI for this.
So in order to Authenticate using AAD B2C you could follow this guide, it should be easy enough to adapt to Python. You simply redirect the user to the /authorize endpoint of the AAD B2C and then validate the JWT you receive
Azure AD B2C supports both OpenID Connect and OAuth 2.0 as noted in the official reference protocols documentation.
To be able to sign-in users with Azure AD B2C using OAuth 2.0 and Flask, you'll need to adapt the sample to follow the OAuth 2.0 approach used in this sample: An Android application with Azure AD B2C using OAuth. Key things you'll need to adapt:
You'll need to specify the B2C authorization and token endpoints: https://login.microsoftonline.com/tfp/TENANT_NAME/POLICY_NAME/oauth2/v2.0/authorize. Example from Android sample
You'll need to add your application/client ID as a scope. Example from Android sample
You won't be able to call the Graph's /me endpoint for token validation and to get user details. You'll need to validate the token and extract the claims from it yourself (ideally through a good JWT open source library since this isn't trivial, unfortunately I don't know any that I can recommend at this time).
EDIT
I've created a python sample for Azure AD B2C and used python-jose for token validation and claim retrieval. Check it out.
Based on the documentation here, Azure AD B2C supports both OpenID Connect and OAuth 2.0 protocols.
Azure Active Directory (Azure AD) B2C provides identity as a service
for your apps by supporting two industry standard protocols: OpenID
Connect and OAuth 2.0. The service is standards-compliant, but any two
implementations of these protocols can have subtle differences.
I couldn't find any clear indication of whether ACS provided this functionality or not.
I would like to leverage ACS to do most of my authentication work, but I would also like access to the identity provider's access/refresh token that was sent to ACS. I can then make API calls to the identity provider to access the user's data such as calendar or profile information (assuming I've requested this access during the application authorization steps).
Is this possible using ACS? It seems as if ACS abstracts most of the underlying identity provider information out, and only provides an ACS token used purely for authentication purposes, not for use in talking directly to the identity provider.
Yes and no :)
ACS does support this feature for the providers that do support that. It is not explicitly documented, because it is not special. ACS does not "just create own token for pure authentication purposes".
If you take the FaceBook IdP, ACS does provide you the FaceBook token, which you can use to query the FaceBook Graph API. And what permissions for the API you will get, depends on what permissions your FaceBook Application will require from authenticating user. I am not sure about the level of sophistication of FaceBook consent framework, but the last I plaid with it, the authenticating user could only Accept all required consents, or reject all. He was not able to selectively chose which consents to grant to your application, out of all requested.
Having said that, from Google Authentication Provider, you do not receive additional tokens. At least with the old OpenID 2.0 imeplementation. Now with the deprication of OpenID 2.0 and moving Google to OpenID Connect, there is a requirement that you explicitly register your ACS Namespace as application with Google. At that point, I assume (speculation of mine) you may declare requested consents, just as you do with FaceBook. And if Google sends the token, you will definitely receive it in your application through the ACS.
ACS is super powerful service that will not die. As in the referenced blog post, all of its features will sooner or later be moved to Azure AD itself. And a migration plan will be provided (hopefully :) ).
But also, note that ACS do only talk with Yahoo, Google, Facebook, Azure AD and any WS-Federation IdP. And WS-Federation protocol is not known for being very flexible and giving you the flexibility you want. ACS in theory also supports OAuth 2.0, but its support does not include Federation, only local identity management (identities local to ACS self).
Also, note, that ACS is being used by a lot of Microsoft owned services, like Visual Studio Online, Azure Service Bus and others. ACS is neither dead, nor will just die letting all its customers on the wild.
You can decide to use it today. Or you can decide to use whatever features are today available in the Azure AD itself. Or wait until ACS is fully migrated to Azure AD.
I've been browsing a lot on both StackOverflow and a bunch of different Microsoft associated sites and looking at examples etc but I think I'm missing a few key point to the problem in hand.
Scenario:
I'm developing a site that uses Yammer (Facebook style page for those of you who don't know) as a Identity Provider together with ACS to provide the security for my site.
Now Iv'e been trying to follow along with a bunch of exercises from MS on how to build those custom providers (Identity Developer Training Kit) but to the question, do I actually have to build them? Isn't there a way to configure ACS to handle my tokens from Yammer (Powershell commands?)? Or do I have to create a STS provider site and "bridge" Yammer and actually provide ACS with my "own" tokens.
So this question is a little bit on an extension on another one.
The ACS does not support OAuth 2.0 for authentication.
As I understand it; OAuth it for Authorization, the ACS is for Authentication.
It does support WS-Federation and OpenID (although only through the API) identity providers, you just need to add the configuration in the ACS.
So if Yammer has an OpenID or or WS-Federation, you're in business.
If not, it's fairly straight forward to build your own identity provider (thinktecture have one you can use as a starting point: http://weblogs.thinktecture.com/cweyer/2009/05/thinktecture-security-token-service-starter-kit---or-look-ma-even-i-can-have-a-sts.html) which you could use to 'bridge the gap' between some other authentication method and the ACS. You would just need to register it as a WS-Federation identity provider in the ACS using it's FederationMetadata.xml file. Your identity provider would then need to determine whether the user is authentic or not.