Located in the BotBuilder-Samples GitHub repo: https://github.com/microsoft/BotBuilder-Samples
There is a sample app: 54.teams-task-module. This app demonstrates a task/fetch action with a Url to a Custom Form which is rendered by a Razor Page.
https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/csharp_dotnetcore/54.teams-task-module
In the Bot, the OnTeamsTaskModuleFetchAsync method is overridden to return a TaskModuleResponse which tells the system to fetch the URL passed back to Teams in the response.
https://github.com/microsoft/BotBuilder-Samples/blob/main/samples/csharp_dotnetcore/54.teams-task-module/Bots/TeamsTaskModuleBot.cs
protected override Task<TaskModuleResponse> OnTeamsTaskModuleFetchAsync(ITurnContext<IInvokeActivity> turnContext, TaskModuleRequest taskModuleRequest, CancellationToken cancellationToken)
{
var asJobject = JObject.FromObject(taskModuleRequest.Data);
var value = asJobject.ToObject<CardTaskFetchValue<string>>()?.Data;
var taskInfo = new TaskModuleTaskInfo();
switch (value)
{
case TaskModuleIds.YouTube:
taskInfo.Url = taskInfo.FallbackUrl = _baseUrl + "/" + TaskModuleIds.YouTube;
SetTaskInfo(taskInfo, TaskModuleUIConstants.YouTube);
break;
case TaskModuleIds.CustomForm:
taskInfo.Url = taskInfo.FallbackUrl = _baseUrl + "/" + TaskModuleIds.CustomForm;
SetTaskInfo(taskInfo, TaskModuleUIConstants.CustomForm);
break;
case TaskModuleIds.AdaptiveCard:
taskInfo.Card = CreateAdaptiveCardAttachment();
SetTaskInfo(taskInfo, TaskModuleUIConstants.AdaptiveCard);
break;
default:
break;
}
return Task.FromResult(taskInfo.ToTaskModuleResponse());
}
I have enabled developer tools in Teams and watched the network requests, as well as overridden every method I can find to try find an extensibility point to inject some sort of token into the request so that the URL can be secured from public anonymous access.
Question: The only way to provide authorization on the Razor Page I see right now is passing the token on the query string and using a custom authorization handler to process the token.
Is there a better way to inject a token or any other info into the task/fetch request so that the request can be authenticated and authorized?
To be clear on this, authentication -is- possible, but only for web pages (Adaptive Cards don't need it). This auth would rely on the standard SSO Teams offers for Task Modules as well as Tabs. See here for intro guidance: https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso?tabs=dotnet, especially:
The SSO API also works in task modules that embed web content.
So really your question kind of becomes "how do I do SSO for web content in Teams". Here's a great video, which includes a link to text (blog) version of the content: https://devblogs.microsoft.com/microsoft365dev/lets-decode-single-sign-on-sso-in-microsoft-teams-tabs/. Here's a working sample, with both Node and DotNet backend options: https://adoption.microsoft.com/sample-solution-gallery/pnp-sp-dev-teams-sample-tab-sso. Note that the samples and docs generally focus on doing an OnBehalfOf (OBO) operation to call Graph, but the principle remains the same - you get a JWT token that you can pass back to your backend, which you can then validate. You can also, from the token, get user info for the logged in user.
From my comments: Looking at it as "Web inside Adaptive" and revisiting the sample project and your information it does seem the "CustomForm" razor page is initializing the Teams JavaScript SDK.
This DOES mean I can authenticate this content using the SSO as you mentioned.
I had only thought it would work in a TAB, not inside a bot card.Solved, follow the tabs javascript SDK guidance.
Related
I created a Teams tab application by customizing the SSO react app sample from the Teams toolkit. The application redirects the user to our website (inside one of the tabs). I can grab the id-token in react (teamsfx.getCredentials().getToken("")) and pass it to our web application via a query parameter.
This id-token is validated and then passed around to various microservices that comprise our backend.
This part works well, but then, we had the need to refresh the token. So, we decided for the web application (written in Angular) to fetch the token using #microsoft/teamsfx and #microsoft/teams-js npm packages.
While I am not certain if that is the way to go, when I execute the following code inside an angular service, it throws the "SDK initialization timed out" error.
try {
const teamsFx: TeamsFx = new TeamsFx(IdentityType.User, {
"clientId": "ee89fb47-a378-4096-b893-**********",
"objectId": "df568fe9-3d33-4b22-94fc-**********",
"oauth2PermissionScopeId": "4ce5bb24-585a-40d3-9891-************",
"tenantId": "5d65ee67-1073-4979-884c-**************",
"oauthHost": "https://login.microsoftonline.com",
"oauthAuthority": "https://login.microsoftonline.com/5d65ee67-1073-4979-884c-****************",
"applicationIdUris": "api://localhost/ee89fb47-a378-4096-b893-***************",
"frontendEndpoint": "https://localhost",
"initiateLoginEndpoint": "https://localhost:8101"
});
const creds = await teamsFx.getCredential().getToken('https://graph.microsoft.com/User.Read');
const token = creds?.token;
console.log("New Token: ", token);
const expirationTimestamp = creds?.expiresOnTimestamp;
this.scheduleRefresh(expirationTimestamp);
this.tokenRefreshed.next({ token: token, expiresOnTimestamp: expirationTimestamp });
}
catch (error) {
console.error("Error in getNewTeamsToken(): ", error);
}
Am I missing anything here, or is the approach itself wrong? Please advise.
Teams is basically just using MSAL under the covers (with a bit of other stuff thrown in I think) to get the token. If you want to be able to authenticate your user outside of Teams, in a separate web app, you can simply use MSAL yourself (something like this I'd guess: https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-angular-auth-code).
That would mean, essentially, that you have a tab web app, doing Teams SSO and then a separate standalone Angular app doing direct MSAL auth. Does you tab app actually do anything? If not, and you're only using it to redirect, you can instead combine these into a single app, and detect in the app whether you're in Teams or not - if you are, do SSO using TeamsFX. If not, do MSAL login directly. This link shows how to detect if your inside of Teams or not.
If you want to continue with separate apps that's fine, but I absolutely would not pass the token as a QueryString parameter - that is extremely dangerous. First of all, tokens are not meant to be passed like this at all, as they could be intercepted. Secondly, passing them on Querystring means that they are entirely open - anything inbetween can sniff the address and lift out your token (if it was a POST payload with httpS, for instance, at least the 'S' would be encrypting the token between browser and server).
I'm attempting to set up the Code Model for Google authentication, so that my user can oauth with Google and my app can retrieve their Calendar data. I'm stuck on step 5 here, where I'm supposed to exchange the authorization code for refresh and access tokens. I'm using nestjs in the backend and React in the frontend.
What I've done already that's working:
User clicks a button on my web app's page
Client sets up google.accounts.oauth2.initCodeClient with the /calendar scope, in ux_mode: popup
User is shown the Google popup and can auth thru that
Client receives a response from Google containing the authorization code
Client makes a POST call to my backend to send it just that authorization code
In step 5, the client makes the POST call to localhost:4000/auth/google-test. In the backend, I'm using the googleapis package and have:
export const oauth2Client = new google.auth.OAuth2(
process.env.GOOGLE_CLIENT_ID,
process.env.GOOGLE_CLIENT_SECRET,
'http://localhost:4000/' // <- note, I'm not sure if this is corect
);
And in the relevant controller route, I'm doing:
#Post('google-test')
public async googleTest(#Body() bodyReceived: any): Promise<any> {
let { code } = bodyReceived
let { tokens } = await oauth2Client.getToken(code)
oauth2Client.setCredentials(tokens);
console.log('Tokens: ' + tokens);
return
The error I'm getting is related to oauth2Client.getToken(code), and the error is a redirect_uri_mismatch. In GCP for the credentials for this app, I've added all of these as "Authorized redirect URIs":
http://localhost:3000/home
http://localhost:4000/auth/google-test
http://localhost:4000
What am I doing wrong?
It took a bit more Googling, but turns out that the right answer is to have my server make the token call with the redirect uri as "postmessage".
This SO question gives a bit more context. A somewhat unbelievable message, but it seems to work for my app.
It is evidently that what is happening is that the redirect URI does not match with the one in the GCP. This usually happens because backend tools such as Nestjs may be appending a trailing '/' to the URL and it may be interpreted as being part of the redirect_uri value.
You can try by temoving any trailing '/' via this following method oauthurl.replace(/\/$/, '')
Moreover, you can pass the generated auth URL to a meta tag. And check the html header to confirm what is the URL value.
i'm trying to use IdentityServer3 to authenticate users on an asp.net webform application with owin pipeline (no mvc)
All the examples suggest to configure the application like a mvc application, but in this way the application doesn't perform a redirection to the IdentityServer Login page when i try to access to a protected resource of the webform application
this is my client (webform) configuration
[Startup.cs]
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationMode = AuthenticationMode.Active,
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie
//LoginPath = new PathString ("/Account/Login") //<--enabling this path property redirect me to a local login page but not to the external IdentityServer login page
});
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
Authority = "https://localhost:44300/identity", //<<--url of the identityServer
ClientId = "webform",
ClientSecret = "ciccio",
Scope = "openid profile roles",
RedirectUri = "https://localhost:44302/", //<-- url of the client (to come back ofter the login)
ResponseType = "id_token",
SignInAsAuthenticationType = "Cookies"
});
i'm sure i forgot something
It looks, you missed app.UseStageMarker(PipelineStage.Authenticate); at the bottom of your Startup.cs.
The reason is that (according to the documentation):
Owin middleware components (OMCs) run at the latest stage, which by default is PreHandlerExecute. The stage markers are used to make them to run earlier.
The complete sample including cookie mapping and support for logout is in IdSrv repo
posting this just in case someone else's still looking a solution for the same problem like we did recently, finding this question without an answer
as workaround i tried these solution suggested in this article but they DON'T WORK
Login page on different domain
both solutions in the example page force a "brutal" redirection to the IdentityServer, but doing so, the IdentityServer doesn't show you the login page because the performed request is not in the correct form
the "signin=xxxxxx" parameter attached to the querystring, needed to legitimate the login request is not present.
i've tried to use an mvc client as well, in this case every requests made to a protected resource (with Authorize attribute) is redirected to the IdentityServer in the correct way (the url where the user should be redirected to log-in page is in this format https://localhost:44300/identity/login?signin=4f7ee6677aec2d2aca6ebc40e4d13720) with the "signin" parameter attached to the querystring
this behaviour doesn't happen in a webform application (at least with the same configuration used in a mvc application)
I'm sure that something is missing, something like a "httpModule" that intercepts the "http 401 not authorized response" and composes a correctr url to redirect towards the login page of the IdentityServer
forgive me for my english
I'm using Windows azure access control service with custom STS. I can login to my application through ACS, but I have trouble with logout function. I've tried this code in my application.
WSFederationAuthenticationModule fam = FederatedAuthentication.WSFederationAuthenticationModule;
try
{
FormsAuthentication.SignOut();
}
finally
{
fam.SignOut(true);
}
Page.Response.Redirect("default.aspx");
But it seems that it logout the user from ACS but not from the custom STS. What should I do to logout from STS. Where could be the problem in the appliacation (RP), ACS or in STS?
I think that ACS should ask custom STS to logout the user, but it seems it doesnt do that. What I am missing?
I have created a helper method for doing FederatedSignout, with comments in the code for what I discovered along the way (hth)
public static void FederatedSignOut(string reply = null)
{
WSFederationAuthenticationModule fam = FederatedAuthentication.WSFederationAuthenticationModule;
// Native FederatedSignOut doesn't seem to have a way for finding/registering realm for singout, get it from the FAM
string wrealm = string.Format("wtrealm={0}", fam.Realm);
// Create basic url for signout (wreply is set by native FederatedSignOut)
string signOutUrl = WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(fam.Issuer, null, wrealm);
// Check where to return, if not set ACS will use Reply address configured for the RP
string wreply = !string.IsNullOrEmpty(reply) ? reply : (!string.IsNullOrEmpty(fam.Reply) ? fam.Reply : null);
WSFederationAuthenticationModule.FederatedSignOut(new Uri(signOutUrl), !string.IsNullOrEmpty(wreply) ? new Uri(wreply) : null);
// Remarks! Native FederatedSignout has an option for setting signOutUrl to null, even if the documentation tells otherwise.
// If set to null the method will search for signoutUrl in Session token, but I couldn't find any information about how to set this. Found some Sharepoint code that use this
// Michele Leroux Bustamante had a code example (from 2010) that also uses this form.
// Other examples creates the signout url manually and calls redirect.
// FAM has support for wsignoutcleanup1.0 right out of the box, there is no need for code to handle this.
// That makes it even harder to understand why there are no complete FederatedSignOut method in FAM
// When using native FederatedSignOut() no events for signout will be called, if you need this use the FAM SignOut methods instead.
}
This code is used in a standard RP library we created for Web SSO with ACS.
The December 2012 update of ACS includes support for federated single sign-out:
Using the WS-Federation protocol. Web applications that use ACS to
enable single sign-on (SSO) with identity providers using the
WS-Federation protocol can now take advantage of single sign out
capabilities. When a user signs out of a web application, ACS can
automatically sign the user out of the identity provider and out of
other relying party applications that use the same identity provider.
This feature is enable for WS-Federation identity providers, including
Active Directory Federation Services 2.0 and Windows Live ID
(Microsoft account). To enable single sign out, ACS performs the
following tasks for WS-Federation protocol endpoints:
ACS recognizes wsignoutcleanup1.0 messages from identity providers
and responds by sending wsignoutcleanup1.0 messages to relying party
applications.
ACS recognizes wsignout1.0 and wreply messages from relying party
applications and responds by sending wsignout1.0 messages to identity
providers and wsignoutcleanup1.0 messages to relying party
applications.
From the Code Sample: ASP.NET MVC 4 with Federated Sign-out, implement an Action like this to sign out from ACS:
(Note that Windows Identity Foundation is now incorporated into .NET 4.5 Framework, that's why the new namespaces below)
using System.IdentityModel.Services;
using System.IdentityModel.Services.Configuration;
public ActionResult Logout()
{
// Load Identity Configuration
FederationConfiguration config = FederatedAuthentication.FederationConfiguration;
// Get wtrealm from WsFederationConfiguation Section
string wtrealm = config.WsFederationConfiguration.Realm;
string wreply;
// Construct wreply value from wtrealm (This will be the return URL to your app)
if (wtrealm.Last().Equals('/'))
{
wreply = wtrealm + "Logout";
}
else
{
wreply = wtrealm + "/Logout";
}
// Read the ACS Ws-Federation endpoint from web.Config
// something like "https://<your-namespace>.accesscontrol.windows.net/v2/wsfederation"
string wsFederationEndpoint = ConfigurationManager.AppSettings["ida:Issuer"];
SignOutRequestMessage signoutRequestMessage = new SignOutRequestMessage(new Uri(wsFederationEndpoint));
signoutRequestMessage.Parameters.Add("wreply", wreply);
signoutRequestMessage.Parameters.Add("wtrealm", wtrealm);
FederatedAuthentication.SessionAuthenticationModule.SignOut();
string signoutUrl = signoutRequestMessage.WriteQueryString();
return this.Redirect(signoutUrl);
}
Have a SAML2 Service Provider web application build on .NET MVC (3). We are using ComponentSpace's SAML2 library to do the authentication, not the Shibboleth SP. Here is the relevant controller logic:
public class SignOnController : Controller
{
// constructor-inject _services
[HttpPost]
public ActionResult SendAuthnRequest(string userName, string returnUrl)
{
// this users ComponentSpace internally to push user to IdP
_services.SamlServiceProvider.SendAuthnRequest(args);
return new EmptyResult();
}
[HttpPost]
public ActionResult ReceiveAuthnResponse()
{
var samlResponse = _services.SamleServiceProvider
.ReceiveSamlResponse(args);
// ...
return Redirect(samlResponse.RelayResourceUrl ?? defaultUrl);
}
}
Ultimately the user lands on either the relay url or the default login page. However when they click a link, then click the back button, the browser goes back to an error page on the Shibboleth IdP server. After that, the browser forward and back buttons ultimately become useless.
Am I doing something wrong in either of the above methods? Should I be returning a View() instead of an EmptyResult() when sending? Is there some way to reset the browser history to prevent repeated postbacks back to the IdP? Is this something that I can configure in ComponentSpace's implementation?
So I understand that you hit back button during authentication in IdP i WBSSO SAML2 profile? I don't know components which you enumerated but in Shibboleth case it always ends with error page. I may be wrong but if you consider the nature of SP->IdP communication I believe there is no other option, unless you reimplement something.
The SAML protocols messages used in SAML SSO as sent via the browser. Clicking the browser forward and backward navigation buttons can be problematic when using SAML SSO, as you have seen.
There is no simple solution to this problem. You could look at incorporating Javascript to disable the navigation buttons but that most likely will cause other issues.
I think the best and simplest solution is to display a generic error message if this occurs. This is something you need to do in your application.
Our MvcExampleIdentityProvider and MvcExampleServiceProvider applications that we ship don't have issues in most cases. They use the SAML high-level API as opposed to the SAML low-level API used in the question but this shouldn't make a difference. In our examples we return an EmptyResult as well.
We faced the same problem and worked around it with JavaScript history API:
https://www.thecssninja.com/javascript/stealing-history-api
It's not nice though since essentially the browsing history is manipulated. But it works efficiently and prevents the error page from showing up. Back/forward buttons inside your web app continue to work correctly but there's no way for the user to get back to any previous page which is not your web app. That was a compromise we could live with.
We use this script. It checks if the main url is called from an SSO redirect. If so, it skips the SSO page when the user clicks the back button. If not, the script does nothing because the back button is working as expected.
(function(window, location) {
var previous = document.referrer.toLowerCase();
var issso = previous.indexOf('account/sso');
if(issso >= 0){
history.replaceState(null, document.title, location.pathname+"#!/skipsso");
history.pushState(null, document.title, location.pathname);
window.addEventListener("popstate", function() {
if(location.hash === "#!/skipsso") {
setTimeout(function(){
history.go(-2);
},0);
}
}, false);
}
}(window, location));