I have a small application which was performing single sign on for logged in Windows Users by implementing my own Credential Provider and intercepting the Logon process and grabbing hold of the credentials. However it appears that with Azure AD login in a non-Hybrid case, grabbing credentials alone may not be the right thing.
Going by the blogs, here and here on this subject, it appears to be the case that in the case of Azure Login, the WinLogon process follows an OAuth workflow talking to Azure AD, using the PRT obtained during AAD Join and obtains an Access Token.
Currently the only way that I could find to get hold of this token is to use WebAuthenticationCoreManager . However I am a background process and my way of getting notified during the Logon Process was using the Credential Provider. To use WebAuthenticationCoreManager API I need to be a Universal Windows App.
How can i implement Single Sign on for my Application, upon Windows Login by an Azure User on a Win10 AAD joined device, using the Access Token issued for the logged in Azure User ?
• Winlogon process cannot be intercepted in Windows 10 AAD joined device because when a user signs in a device joined with or registered with AAD, a PRT (Primary Refresh Token) is generated which is an opaque blob sent from Azure AD whose contents are not known to any client components. You cannot see what’s inside a PRT.
• Also, a PRT contains claims generally contained in any Azure AD refresh token along with the device ID and a session key where device ID is used to determine authorization for Conditional Access based on device state or compliance and session key acts as the proof of possession when a PRT is used to obtain tokens for other applications.
• Please find the below token issuance flow during sign in process which clearly shows that token issued by Azure AD is verified by the CloudAP or local security authority based on the device certificate or trusted authentication protocols wherein it is saved as cache.
• However, you can add your app as a generic app in Azure AD for the SSO to be configured and used with it.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications
https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
Related
I have searched far and wide to find out how I can change the settings of my Microsoft Graph app so I only allow login from my own domain.
Since the login from Graph takes all Microsoft accounts i've been looking into different solutions, all from finding custom token endpoints to changing the application manifest.
In my manifest I can find this "signInAudience": "AzureADandPersonalMicrosoftAccount" - but I can't find in the documentation what other options there are.
also on this Microsoft page I can find this information
The overall solution comprises the following components:
Azure AD – If the Restrict-Access-To-Tenants: <permitted tenant list> is present, Azure AD only issues security tokens for the permitted tenants.
Is there any good guides online or anyone who knows how i can restrict access to people signing in either with #xxxxx.comonly or xxxxx.onmicrosoft.com accounts?
I think you're misunderstanding how Microsoft Graph works. It connects to the tenant/domain of the user authenticating. So if I authenticate with user#contoso.com, the application will only have access to the contoso.com tenant.
In terms of the authentication process itself, this is handled by Azure AD. Microsoft Graph simply accepts the token AAD returns. You can limit this process to users from a given tenant by changing the /Authorization and /Token URLs your app is using.
In most cases, apps use the /common tenant. When a user authenticates against /common, AAD handles discovering the user's actual tenant/domain and routes the request to that AAD instance for processing. These URLs look like this:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
If you want to limit authentication to a single tenant, you can skip the discovery process and force AAD/OAuth to authenticate against a single AAD tenant. Only users that exist in that tenant will be able to authenticate. This is done by swapping /common with tenant's id:
https://login.microsoftonline.com/xxxxx.onmicrosoft.com/oauth2/v2.0/authorize
https://login.microsoftonline.com/xxxxx.onmicrosoft.com/oauth2/v2.0/token
Currently, the implicit grant flow URL to get access tokens from Azure AD by our SPA (native web app running in Azure VM) is of the format:
https://login.microsoftonline.com/{{tenantID}}/oauth2/authorize?response_type={{responseParams}}&client_id={{applicationID}}&redirect_uri={{redirectUri}}
Here, responseParams= id_token is the default value passed by Adal.js. What would be the changes needed to be made to this URL to get back refresh tokens from Azure AD?
The implicit grant flow does not issue refresh tokens, mostly for security reasons. A refresh token isn’t as narrowly scoped as access tokens, granting far more power hence inflicting far more damage in case it is leaked out. In the implicit flow, tokens are delivered in the URL, hence the risk of interception is higher than in the authorization code grant.
However, a JavaScript application has another mechanism at its disposal for renewing access tokens without repeatedly prompting the user for credentials. The application can use a hidden iframe to perform new token requests against the authorization endpoint of Azure AD: as long as the browser still has an active session (read: has a session cookie) against the Azure AD domain, the authentication request can successfully occur without any need for user interaction.
This model grants the JavaScript application the ability to independently renew access tokens and even acquire new ones for a new API (provided that the user previously consented for them. This avoids the added burden of acquiring, maintaining, and protecting a high value artifact such as a refresh token. The artifact that makes the silent renewal possible, the Azure AD session cookie, is managed outside of the application. Another advantage of this approach is a user can sign out from Azure AD, using any of the applications signed into Azure AD, running in any of the browser tabs. This results in the deletion of the Azure AD session cookie, and the JavaScript application will automatically lose the ability to renew tokens for the signed out user.
Reference: Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
How SSO woul work if you have 4 applications which you want to secure them using OpenID Connect token from ADFS?
These 4 applications has no user registery, however they need different claims from IdP (ADFS). Do you need to create 4 different user accounts for each user to be able to log on into all 4 applications?
If you need 4 different user accounts for each user, then do the user need to log-out first from app_1 and log-on on app_2?
I appreciate all kind of advice.
Assuming each application receives an ID Token from ADFS in OIDC mode, then each application as part of that ID Token will have access to the subject/user id, and can exchange that ID token for the user profile. ADFS running as OIDC OP will need to be configured to release the proper claims for each application, and of course each application should be requesting the proper needed scopes on initial authentication so ADFS can grant the claims needed.
Each application receives an ID token, and begins to establish their own session tied to that user. Since application sessions are independent of the SSO sessions, you need a coordinated effort if you need to implement single logout.
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.