I am looking for some guidance on how I can use an Azure B2C custom policy to federate to a legacy Authentication Server. Here is the current flow that I would like to implement in the custom policy.
This protocol looks like a hybrid Oauth1 and the "actors" involved are:
Browser based user
Application Server
Authentication Server + protected resources
The Application server is preconfigured with an application id and an application secret provided by the Authentication Server. The Authentication server is also configured with a callback URL (pointing to the Application server). - Similar setup to OAuth.
Flow:
Step 1: The user requests a resource from the Application server by performing a GET on the application server (e.g. GET /resource
Step 2: The application server calculates an attribute using the preconfigured client secret and redirects the browser to the Authentication Server.
Step 3: If the Authentication Server determines that the user needs to be authenticated and may prompt the user for a username/password. This is transparent to the application server.
Step 4: The Authentication Server verifies the application server-provided attributes sent in Step 2 and responds by redirecting the user to the preconfigured application server callback URL. This request will additionally include a number of attributes set by the authentication server.
Step 5: The browser redirects the user to the application server’s callback URL and the application server uses the attributes received in Step 4 to calculate a resource request token
Step 6: The application server uses this request token to request protected resources and responds to the user's original request.
I am looking for ways to implement the above. Do I build this using a custom policy with an Oauth1 Technical profile Or an OIDC technical profile or something else?
The only way to do this is to create some middle layer than talks OpenId Connect to AAD B2C and talks the proprietary protocol to your legacy system.
Azure AD B2C can then make an open id connect request to your web server and it can do whatever it needs. Just have it respond back to B2C in an open id connect way.
Related
I have a web app configured in my Azure AD.
On a machine, i have installed a connector and configured an application proxy with that connector.
I am now trying to connect from an Android mobile application to the web app through the application proxy.
If I use a WebView inside my app, I can load the User access URL, enter my credentials and I receive a cookie for use by following connections.
I need to be able to use other HTTP clients that do not have the possibility to show UI.
I was wondering if it was possible to somehow request access and refresh tokens, and add those to future requests. or if possible convert them to a cookie in some manner and add that in a header.
Your client app can simply use MSAL (or ADAL, or another OpenID Connect client library) to sign the user in and an access token for the App Proxy app. Then you can include that token in the Authorization header in requests to the endpoint from App Proxy. App Proxy will recognize it, validate it, and (if everything checks out) proxy the call down to the App Proxy connector, where the rest of the process happens as normal.
Here are the relevant docs: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-native-client-application
I have an ASP.NET MVC application that authenticates users against Active Directory.
As I understand this is the process happens when a user logs on to his computer:
User enters credentials on the local machine.
Local machine checks if it already has an authentication ticket for these credentials.
If not, it contacts the first ADS server it can find that offers kerberos authentication functions
The ADS machine checks the credentials against the LDAP database.
If they check out, kerberos returns a TGT (ticket-granting-ticket) to the client machine
For a certain duration set in AD (usually 8~10 hours) this TGT will bypass any credential checking in case the local machine user wishes to connect to resources that require permissions not present in his bare user account (i.e. group memberships, additional machine and share access, etc.)
My question is how does IIS know about the TGT when the browser is making a request to it for my app? Does the operating system send it out on every outbound http request to every single website?
The server (IIS) will indicate to the client (browser) that it needs to authenticate by returning an HTTP 401 error code with a WWW-Authenticate header. The client detects this and determines if it can correctly authenticate. The way this works is as follows:
Determine who the requestor is by checking it's Service Principal Name. It exists as {type}/{fully.qualified.domain}, e.g. HTTP/resource.domain.com. This SPN is mapped to a machine or service account in AD. If this SPN isn't registered, the client falls back to a lesser protocol like NTLM.
Local machine uses the TGT to request a service ticket from AD. AD validates the TGT and looks up the SPN in the request and if found creates a service ticket encrypted against the password of the account associated to the SPN.
Client sends the service ticket to the server via Authorization: Negotiate YII... header.
Server decrypts the service ticket using the password it's been provided, either through a domain join, Windows Service Run As config, or keytab.
Server transforms the contents of the decrypted service ticket into a Windows identity.
Identity is presented to the application.
This flow isn't inherently web-specific. This is how all services authenticate themselves when using Kerberos.
I created an Azure Mobile App Service which is currently accessible 'Anonymously'
Anonymous access is enabled on the App Service app. Users will not be prompted for login.
To make it secure I can enable App Service Authentication which will ask users to log in
But this is not what I want - The data in this app is only accessed by Application without the need of each and every user to login to my app before using it.
So you might say, in this case, Anonymous access is fine but I want to restrict it with something at least like an API Key so I will have access to the API which my app can use to access the data to prevent random requests as anyone can just go and use Postman and start getting data without any authentication.
So in short, I don't want individual user authentication, but at least an API Key to ensure only requests made from my app are authenticated and nothing else.
I am using the following in my mobile app to create a connection and also doing Offline sync etc
MobileServiceClient client = new MobileServiceClient(applicationURL);
Any idea how do I do that?
FYI. My server side backend is in C#
Since you are using Azure Mobile Apps, for your requirement, you could leverage Custom Authentication for building your CustomAuthController to login and generate the JWT token for a specific user without user interaction. The core code snippet for logging would look like as follow:
MobileServiceClient client = new MobileServiceClient("https://{your-mobileapp-name}.azurewebsites.net/");
client.LoginAsync("custom", JObject.FromObject(new{Username="***",Password="***"}));
Note: As the above tutorial mentions as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
And you must explicitly add [Authorize] attribute for your controllers / actions which need to be authorized access. Details you could follow Authentication in the Backend.
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/
I'm working on a security setup suitable for the following client/server scenario, and I'm having a couple of questions/considerations that I'd like to share with you.
Situation:
I have a number clients on different platforms:
HTML-client (single page apps (SPAs) using jQuery/AJAX)
Android-app
Silverlight client
Windows client
Windows Mobile client
The large majority of the corresponding server components are based on .NET WCF using REST (but for some backends, I'm using other protocols).
I've found the open source project IdentityServer v2 from ThinkTecture to be a nice and flexible security token service (STS) for my solution. It supports a number of token types, protocols and is highly extendable and has a self contained Identity Provider (IdP) based on ASP.NET Membership database if needed.
The basic flow for clients using usernames/passwords is as follows:
The client makes an unauthorized HTTP call to a ressource (that requires authorized access) on its server
As the client is not yet authenticated, the server returns a HTTP 401 (unauthorized) providing an address to the STS in an HTTP Location header (see note on this below)
The client submits its credentials to the STS in a HTTP Basic Auth header
The STS returns a JWT token containing all relevant user claims
The client now repeats its initial request from step 1 including the JWT token in the HTTP Auth Bearer header
The server validates the token, as it originates from a trusted STS source, and returns the requested ressource
I know that step #2 is a bit unorthodox in combining the HTTP 401 error message with a HTTP Location header normally associated with the HTTP 3xx status codes. I need the 401 status code because of my jQuery/AJAX clients which handle the 302 redirect message automatically without any chance to interscept the redirect.
Now, the system needs to use an external IdP. The "internal" STS is customized to forward auth requests to the external IdP handling transformation of claims from the external IdP format to the internal format. One catch with this is that it implies the "password anti-pattern", but for now all systems are interal and trustworthly.
Could WS Federation be my friend?
The above basic flow applies to at all clients, browser based or not. But for specifically browser clients, I've been looking into a federated security scenario, having the resulting IdP/STS to provide a login mechanism for the clients. The STS that I use (IdentityServer) can be configured to be used in conjunction with a WS-Federation compliant STS. Thereby tokens are automatically transferred to the target token format (in my case for instance from the external STS's SAML token to the internal JWT token).
With this I can have some sort of a SSO mechanism.
Now my questions:
Is my described basic security flow optimal?
Is WS-Federation only applicable for browser clients?
If not, how can it be used with for instance my android clients?
In WS-Federation with more STSs, how is the communication flow between: client - internal STS - external STS (in terms of HTTP communication, cookies and stuff).
I don't think what you describe is WS-Fed. WS-Fed never involves 401 and never involves authentication headers.
WS-Fed has two versions, passive and active.
Passive is for browsers. It consist in 302 to the identity provider which in turn POSTs the SAML token back to the caller. The authenticaiton is then supported by cookies.
Active is for active clients (applications). It consist in a SOAP response that instructs the caller to go to the identity provider for the token. The SOAP response from the identity provider contains a token which is then supplied to the service.
What I believe is that the active scenario is quite complicated if your client doesn't support the WCF federation authentication binding (wsTrustFeb2005). You'd have to implement the flow on your own.
What I'd like to recommend instead would be the OAuth2 flow. OAuth2 has 4 different flows, of which two correspond to WS-Federation's active and passive: authorization code flow is for browser-based apps and the implicit flow is for desktop/mobile applications.
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#authorization
OAuth2 integrates easily with WebAPI services and there is a great support for it in the DotnetOpenAuth library.
This and other authentication/authorization options are described in great detail in the Pro ASP.NET WebAPI Security book
http://www.amazon.com/Pro-ASP-NET-Web-API-Security/dp/1430257822
Even if you are not planning to build your backend around WebAPIs (but rather RESTful WCF as you mention), the book will give you necessary background on OAuth2.
On the other hand, if you still insist on WS-Federation, this free e-book describes both active and passive scenarios:
http://msdn.microsoft.com/en-us/library/ff423674.aspx