I am trying to understand how smartcard auth happens over Azure. I Understand that we require on-Prem ADFS however I am trying figure out two things:
1) What exact exchange takes places between Azure and client? Something like below:
GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token+code&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post&scope=openid&resource=https%3A%2F%2Fservice.contoso.com%2F&state=12345&nonce=678910
2) How is Smartcard Authenticated? Is it a challenge response or the certificate is verified? In case of challenge response the client generates a signed data that is verified by ADFS?
1)What exact exchange takes places between Azure and client?
The sample request you mentioned is a sign-in request to get access tokens, for the exact exchange between Azure and client, just refer to this link.
2) How is Smartcard Authenticated? Is it a challenge response or the certificate is verified? In case of challenge response the client generates a signed data that is verified by ADFS?
I think it may be a challenge response, and the client will generate a signed data that is verified by ADFS.
You could refer to this article, as mentioned in the How federated access works with Windows Azure (Step 4) :
The KDC issues the client a Service Ticket, containing the multifactor claims (this assumes that IT policy forced smartcard authentication at desktop login time, otherwise, AD FS can challenge to present a smartcard during this Windows Azure Management Portal login sequence).
The client PC presents the Service Ticket to AD FS. AD FS validates the Kerberos ticket and generates a signed SAML token for Windows Azure AD in the next step. AD FS will only send the signed SAML token if the credentials are valid.
Related
I want to enable my API to start accepting tokens issued by any identity provider (like other Azure AD, Okta - I'll keep client ID and authority in my settings), one request comes for Azure another will come for Okta, so by looking at the token, I should be able to validate it and send response.
Any right approach or technical correction you can suggest?
in progress code file- start.cs
I already made the authentication flow with the Microsoft Graph/Azure AD authentication. Once I get the authenticated user's token I store them in his cookies. To validate the user's token I call the Microsft Graph API resource /me. This does not seem a good approach because basically everytime time a client does a request to my API, he is basically doing 2 requests because my API requests Azure AD for validation.
Is this a good flow?
No, it isn't.
Your front-end should acquire an access token for your API, which the API can verify using its digital signature.
The token will contain some info about the user as well as the app that acquired it.
The way in which the front-end acquires the token depends on the type of application.
Front-end single page apps use implicit grant flow for example.
Do note that you have to specifically ask for an access token for your API.
As long as your back-end is then configured with standard JWT Bearer authentication,
all is handled.
This is done by specifying the authority as your Azure AD tenant (or the common endpoint if it's multi-tenant),
and the standard bits for JWT authentication should download the public keys from Azure AD's metadata endpoint, which it can then use to verify validity of any access token it receives.
You do not have to validate tokens for an api that's not yours (issued to your AppId Uri).
For example, Graph validates the tokens that are sent to it (issued for "https://graph.microsoft.com).
If you build and register in Azure AD an Api of your own (say AppIdUri="https://myapi.mydomain.com"), your clients will request and receive access tokens with aud claim set to "https://myapi.mydomain.com".
The clients themselves don't need to validate the access token issued for your Api But your Api, when it receives those access tokens, has to validate them. The validations, among other things will validate the access token was issued to "https://myapi.mydomain.com".
Try out this sample, to get a good understanding around concepts of token validation.
I have ASP.Net Web API and I want to authenticate my API using Twitter Digits Auth and later will pass that Digits token to Azure Active Directory Auth Service.
I got an idea about Twitter Digits Auth but I'm confused how can I pass Digits token ahead to Azure Active Directory Auth Service.
Please see this diagram which I'm thinking to implement.
Does Azure Active Directory Auth Service mean Azure App Service Authentication and Authorization. If I understand correctly, this scenario will not work.
The Azure App Service Authentication and Authorization supports two kinds of authentication flow, client-flow and server-flow. The scenario you mentioned is client-flow which acquire the token from identity data provider first and then exchange the access token with Azure AD using that token. However in this scenario, we need to using the token issued from the identity data provider(Azure Active Directory, facebook, google, microsoftaccount, or twitter.) directly.
If I understand correctly, the Digits token is issued from Digits which the Twitter supports. This token is not supported for the Azure App Service Authentication and Authorization. You need to check whether the Twitter support to exchange this token for the token issued from Twitter.
More detail about the client-flow you can refer this document.
I need my mobile application to allow authenticating either to 3rd party vendor (facebook, google, etc) or to my own WS-Federation identity provider (I'm using Thinktecture). Now, when logging in to my own WS-Fed idp I want to authenticate directly and pass the security token to Azure ACS (and not by using a dedicated login page). I need that because I don't want my users to authenticate using my provider by using a dedicated web page (and moving out of the context of the application).
Your help will be appreciated.
From your ACS management portal get list of identity providers of your realm from below link
https://YourNamespace.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?
protocol=wsfederation&
realm=YourAppRealm&
reply_to=YourAppReturnURL&
version=1.0
Now try this:-
HTTP GET on the above identity providers link.
Parse login link of desired identity provider from the json response of above request.
Authenticate user with login link received in last step.
You'll receive your ACS Token
Note:
After step 3 user will be asked to authenticate himself and the identity provider will automatically send the authentication token to ACS, finally ACS will convert that token into new ACS token and return it as in step 4.
In this way you'll by-pass the login page and can grab ACS token in mobile application without moving out of the context of the application.
I am trying to log in to Azure Mobile Service using the authentication token but getting this error: "The authentication token's signature was malformed or signed by a different key." I am using Facebook as Authentication Provider.
for the record, I have obtained the authentication token by logging in first.
The authentication token you receive from "authenticating first" to Facebook or another social network may be different than the one you would get from authenticating via Azure mobile service to that network. This is why your token would be "sign by a different key". For what it's worth, it's no different than trying to use a token acquired from another site that uses social login and using it in your site. You can only use the token that is signed with your key.