We are using a third party STS for iDM (not ADFS), when the user logins, on the relaying party side we are getting all the claims we need.
To connect to sql server, I need a windows token, and I read at MSDN blogs that I can use C2WTS service to get a windows token. STS is sending the upn claim to the application
Is it possible to get a windows token using C2WTS when we don't have ADFS but a SAML token with the right claims (including upn claim) from another STS?
C2WTS is installed as part of WIF not as part of ADFS. It is not tied in ADFS in any way.
So if you have the "mapToWindows" attribute set in your app's web.config (as below), the claim (sent from an STS) will be intercepted and converted to a Windows token.
<samlSecurityTokenRequirement mapToWindows="true" useWindowsTokenService="true" />
You need to turn the service on and configure the C2WTS web config. file to allow the correct user's through.
Related
We have an MVC application (<myapp.somedomain.com>) .net 4.5.2 (OWIN/ADAL) that uses ADFS2016 for AuthN/AuthZ via OIDC/OAuth2. Users' credentials and attributes are stored in AD LDS. A client (X) requested to authenticate in the application via their IdP over SAML2. Is this possible WITHOUT making changes to the application?
The flow I am looking for; for this client the app’s URL would be (<myapp.somedomain.com/?client=x>). Our ADFS would recognize and redirect the client to their IdP where they would authenticate and than they would be send back to our ADFS along with some predefined claims. Our ADFS would map these claims to an Id Token / Access Token for our application to use. Am I dreaming or is this indeed feasible?
Any links to articles / documentation on how this could be achieved would be most helpful.
As #Wiktor suggests, you could add a SAML client-side stack to your app.
The other way is to federate ADFS with the SAML IDP.
When the user is redirected to ADFS, they use Home Realm Discovery to either redirect to the SAML IDP or authenticate on ADFS directly.
ADFS should handle the token conversions but you may have to fiddle around with the claims rules.
I have created a Single Page Application with Angular and authentication/authorisation is managed by Azure AD. I have used MSAL.js to initiate the implicit flow.
Everything is working fine, but now my client wants to use her own identity provider (IDP) so that users have a single point of entry for all apps (including mine). This IDP is not mainstream, it is built in-house by the client;
I want to keep using Azure AD to manage authorisations (groups, roles...). I also want my application and its dedicated backend API to be registered in Azure AD, not in the third-party IDP.
Azure AD should remain responsible for providing the Access Token to the SPA in order to call the API.
Somehow, I should redirect the user to the third-party IDP login form and upon successful login it will redirect to my SPA, which should then associate the tokenID with an AzureAD account and retrieve the Access Token (I suppose I will have to create an account in Azure AD for users identified in the third-party provider)
However I'm having a hard time figuring out how to achieve this and if it is at all possible ?
What would be the recommended approach for this scenario ? Can I still use MSAL.js or do I have to rely on something else ?
ARCHITECTURE
Your goals are completely correct and you should not need to change a single line of code to integrate a new IDP - so you can continue to use MSAL.js.
PREREQUISITES
In order to integrate their own IDP into your system you need to insist on certain prerequisites:
The client needs to provide a Standards Compliant Identity Provider
Typically the IDP needs to communicate with your Authorization Server (Azure AD) via either Open Id Connect messages or SAML2P messages
A home grown IDP may not meet these prerequisites in which case you need to explain to the client that they need to get standards compliant.
HOW FEDERATION WORKS
Your UI will redirect to your AS
The AS will redirect to the IDP, when given a trigger
The user will authenticate in the IDP
The IDP will post a token to your AS to identify the user
The AS will issue another token to your UI
Note that there is no coding involved here - there is only standards based integration between vendor systems.
WHAT THE CLIENT WILL GIVE YOU
Client details are often supplied by giving you their metadata document, and these details are then configured in Azure AD as a trust entry:
The entity id of the IDP
The token signing public key for IDP tokens, so that your AS can validate them
A URL to redirect to
WHAT YOU WILL GIVE THE CLIENT
A similar trust entry will need to be configured in the client IDP so that it trusts requests and issues tokens - though no certificate is usually needed here:
The entity id of the AS
A URL to post tokens to
TRIGGERING THE REDIRECT FROM THE AS TO THE IDP
One option is to forward the entity id to the authorization server in Open Id Connect redirects. Often an 'idp' query parameter is used, something like this:
Client accesses your app with a bookmarked URL:
https://app.mycompany.com?idp=urn:client.com
You add an extra parameter to the Open Id connect redirect to tell it where authentication should happen:
https://login.mycompany.com/authorize?client_id=XX&idp=urn:client.com
AZURE AD SPECIFICS
Once you understand the high level process there is some technical stuff to configure the connection and you'll need to consult vendor documentation, such as this Microsoft Azure B2B article.
PRACTICE
If you haven't done this before then you need to invest some time to get a connection working and then document the process.
You can use Windows Server and ADFS to simulate a client connection, then integrate it as a SAML2P connection. There is a learning curve though, and you'll need infrastructure such as ADFS certificates.
We're in a scenario where a single page application that we develop ourselves (AngularJS front end with https server APIs in the back) opens another
web application developed by a partner of ours in a new browser tab, and where this second web application needs access to a https server API that is also developed by us.
After looking around for possible solutions, we have now created a proof of concept using IdentityServer4, where the second web application is configured as a client with "authorization_code" grant type. When all applications are running on the same domain, the third party application is able to access our https server API without being prompted for user id and password.
The implementation of the second web application in this proof of concept is very much like the solution presented by bayardw for the post
Identity Server 4 Authorization Code Flow example
My question now is:
When - in production - the second web application no longer shares domain with our application and our https server API, will a call from the second web application be prompted for username and password when accessing our http server API?
Seems, you are missing some major things. First of all any API should never ask for username and password. Instead your app(s) should put a token into each request and API should validate that token. Where the user credentials should be asked is when a user accesses your (or 3-rd party) web application. Then Identity Provider creates an Identity token (usually to be persisted in a cookie and used within the app) and access token (to be provided to APIs). Each token is issued for specific Client (app) pre-registered in IdP. Probably when been hosted at the same domain your two apps shared the identity cookie and Client Id what is not correct. In production scenario you have to register the apps separately. All the rest should work fine (if you follow the routine i briefly described at the beginning).
Chosing to post an answer myself from feedback through other channels:
This boils down to the session tracking of the IdP. If cookies are being used to track IdP session, the behavior is impacted by whether a session cookie or a persistent cookie is used.
In general, I have found that Robert Broeckelmann has great articles on medium.com.
We want to code a web-application (with ASP.NET Core) that starts a legacy Windows desktop application via a custom URL protocol. The web-application must use an authorization server for obtaining an access (bearer) token via OAuth 2 with which it has access to the user's resources via an ASP.NET Core Web API. The desktop application must be able to access the user's resources via the Web API too. How can the desktop application obtain an access token?
I can think of the following options:
The desktop application shows a login screen, sends the entered username and password to the authorization server (using the “Resource Owner Password Credentials” grant type of OAuth 2) and gets an access token back.
The desktop application shows an embedded browser window. The embedded browser requests the OAuth Authorize endpoint of the authorization server (using the “Authorization Code” grant type of OAuth 2) and the user must log-in to authorize. The authorization server redirects back to the redirect URL. The desktop application intercepts this redirect, extracts the authorization token and uses it to get an access token.
The web-application starts the desktop application and passes its access (bearer) token as an argument to the desktop application.
Before starting the desktop application, the web-application requests a new authorization code from the authorization server. The web-application starts the desktop application and passes the authorization code as an argument to the desktop application. The desktop application exchanges the authorization code for an access token by sending the authorization code to the OAuth Token endpoint of the authorization server.
We do not wish to use the first and second option, because we want single sign on.
The third option does not seem to be a good idea, because malicious software on the user’s desktop PC can obtain and use the access token too.
The fourth option seems to be the only option left. As far as I know an authorization code is a temporary (short-lived) one-time token. Besides that, you need to know the client secret for obtaining an access token.
Can anyone confirm that option four is the way to go? Or did I overlook something?
Are there any examples with IdentityServer for this scenario?
Both application should share a logon session using the system browser. This way the user gets SSO in the native app (and even vice versa).
The spec describes the best practices for native apps:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-12
In your case there is a flow that is made specially for desktop application:
Client Device Flow for OpenID connect allows Application that do not have any "browser capability",this Flow will typically suit well Desktop applications.
I have a Windows Phone application which is reading and writing data from a WCF Data Services service which is hosted in and ASP.NET MVC 3 application.
I can configure both client and server as necessary. I'd like to use OpenID if practical, and once a user is authenticated on the phone they should be able to browse through data which is associated with their OpenID.
How should I configure client and server to make that work?
To use OpenID in your app you should look at using an embedded WebBrowser control which connects to the provider site (or your site which can redirect). When the OpenID provider returns to your site (embedded in the browser control) you'd pass necessary identifiers back to the app.
There's an example of doing this with a twitter app (using OAuth) at http://blog.markarteaga.com/OAuthWithSilverlightForWindowsPhone7.aspx
OpenID is an awkward choice. It sounds like the user already has data associated with their account, which means that the user would have to login to the server at some point in time to set up this data, and then login to the app with the same credentials to access this data. The issue is that of securely verifying that the client app has indeed authenticated the user in question. Assuming that the client app (somehow) has the user's OpenID is not enough because the server can't implicitly trust what the client app tells it.
Off the top of my head, I'd say, what could be done with OpenID is as follows.
First, set up OpenID authentication on the server. Then, when the client app needs to authenticate, it should use the WebBrowser control to point to a server URL that, in turn, lets the user authenticate with their OpenID provider, and points the browser back to the server with the authentication info. At this point, the client app is unaware of the user's authentication status, but the server knows who they are. Now, the server can generate a single-use auth key for the client to use. It can redirect to a special URL with that key in it, at which point the client detects said URL, extracts the key, hides the WebBrowser control, and uses that key to talk to the server. I believe that would be a secure way to do such authentication, but like I said, this is just off the top of my head.