I'm trying to figure out how to integrate the identity server with azure mobile services for use from mobile clients. I already have the id server up and working barebones with a test aspnet mvc website using it via the openidconnect middleware.
I haven't found much info on how to do this with mobile services and I'm not exactly sure what the overall flow is as far as what talks to what first. Is it that the mobile client should call the id server directly posting the username password and getting a token and then set that token on the mobile user then, when calls are made to azure mobile service the token is then validated on a back channel from the service to the id server? Or how should it work?
I have already read the custom authentication docs on azure and found some azure team blogs on the subject but it seems like they are already out dated. Is there a way to simply insert the same openidconnect middleware into the azure pipe?
I'm hoping to get this ironed out because I have a number of web+native mobile (Xamarin) projects on the horizon and this would be the identity foundation for all of them.
Related
I’m trying to setup authentication & authorization for my Express based Node JS, REST API with azure AD. I’m not sure if that is possible without 3rd party libraries like Auth0.
API will be invoked from both client side (react, angular) & server side(asp.net, RPA) applications. I’d appreciate if you can share some tips on the architecture, examples and where authentication and authorization can be done. I think authentication will happen in the front-end(????).
End of the day I need these apis to be invoked only by authorized applications, users and I should be able to identify user’s invoking these apis.
you can get your NodeJS apis protected with Azure AD. To achieve this, you can either use MSAL-Node or Passport-Azure-AD libraries. Once these APIs get protected by AAD, any front-end apps or back-end services calling your AAD protected APIs must fetch an access-token from AAD first and then use that access-token as bearer and call the AAD-protected APIs.
To get you started, you can refer to the following quickstart guides for both the libraries:
Quickstart guide for MSAL-Node: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-nodejs-webapp-msal
Quickstart guide for Passport-Azure-AD: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-nodejs-webapp
I have created a new ASP.NET web site using VS 2017 and changed the Authentication mechanism to use "Individual User Accounts". This adds the Claims Principal or WIF class support.I can click on register / log in, and set up user emails and then check for the claims for that user. I will also be using Server Session Authentication Management (SAM) to save claims on the server and do some claims transformation as well.
After Login, this site calls a winform application, and after some activity I return back to the above website.
I want to know how can I use SSO logic here and check if I am already Authenticated and access my claims saved at the server side / website and authenticate the user based on the saved claims.
Is there some project or code example anyone can give which i can use as a start to develop such a STS service (in VS 2017) with SSO and access my claims on website after coming from another domain?
The identity and access tools used to work only with VS 2012, so any way to replicate the above scenario and check for my saved claims after I hit my website from the winform application.
There's a good example here of using WS-Fed with Azure AD.
This is easily adaptable to ADFS.
Your other choice is to use ADAL.
I am starting to work with Dynamics 365 Portal add-on (Online, not on-prem), which I've configured to use an external authentication provider in the form of Identity Server with OpenId Connect. The problem with this is that I don't have access to the under-the-hood portal authentication process, there's just a few basic config settings and users can authenticate using the external IdP. I can't access roles, claims, or any custom info that might come back as part of the OpenId Connect user's profile (userinfo object response). I need to get at that data to customize the portal user experience. I've looked through whatever documentation I could find on the portal but can't find anything. Am I missing something or is it just not possible to access that info and customize the portal login process? Since it doesn't seem possible to do anything server-side within the portal because it's Online, can I do anything client-side within the portal to get the OpenID access token and call the UserInfo endpoint with that?
I had a case open with Microsoft and finally got an answer from them: In Dynamics CRM Online with the Online Portal add-on, there is currently no way to access anything coming back from an external identity provider. So for example, if you've configured the portal to use an external identity provider such Google, Facebook, etc, or like in my case an Identity Server instance with OpenId Connect, you can't access the claims or any other info coming back from the provider.
UPDATE:
I got another response from Microsoft support: they have confirmed their dev teams are working on making this available but don't have an ETA yet. At least it's on their radar.
We are migrating our Google Apps Marketplace Apps to OAuth2 authentication.
We have figured out some of difference in migration process such as replace OAuth1 two-legged authentication with Service Account OAuth2 strategy to impersonate domain and perform some background task.
In our current OAuth1 apps we have some queries to customerLicense service to check if some domain removed our App from Marketplace.
I have seen this is not possible to do with OAuth2 by the moment. Is there any Service with Service Account OAuth2 that replace this mechanism to check customerLicense for a specific Application?
Since I am using only service account keys I have not found documentation about how to consume this API with these type of credentials. In fact documentation says only Oaurh two legged keys are able to consume this API.
Can you send me some link where I can read about consuming this API with service account Keys?
Best,
You should be able to use the same API with OAuth2. If there are any issues please let us know.
According to the documentation it only seems possible to authenticate against the windows azure service management API by attaching a certificate to each request which I previously have uploaded to the management portal.
The new management API has been built using the service management API, but it uses windows live authentication. Is it possible to use windows live to get the windows azure subscription ID and the certificate, so I can use the same authentication mechanism the management portal uses?
What makes you think that the Service Management API uses Live ID for authentication? It is just the portal that uses Live ID for authentication.
If you dig a bit you will notice that all the service requests from the management portal are made against https://manage.windowsazure.com/Service while The Base URI for management service is: https://management.core.windows.net
So, No, you can't authenticate against the Management API with Live ID. Moreover, it is the Management API is not new. The portal is New. The management API has been there for a while and is updated from time to time to reflect new services that are coming.
UPDATE AFTER THE 2 COMMENTS
Following Gaurav's explanation I will just add a simple architecture diagram (super simplified and totally my thought, but this is how would I build it in very minimalistic way):
[User's browser (portal)] ==> Sends XmlHttpRequest (AJAX) to ==> [Portal Service]
then
[Portal service backend] ==> signs request with predefined certificate and sends request to ==> [management.core.windows.net/subscription-id/whatever/service/command]
This actually is a very common practice to provide UI to a (web) service.
This way both conditions are implemented:
You use Live ID to authenticate with the portal
The Windows Azure Service Management API are yet, still and only protected by a Certificate.