How do I log out of Facebook when using Azure's ACS? - facebook

Rule #6 of the Facebook developer policy says I must provide an explicit Log out link, but I'm unable to make it work.
My goal is to either sign my application out of Facebook, the user from the entire Facebook experience environment, or both. So far, I can't do any of these.
This may be complicated by the fact I'm using Azure ACS and am not using the typical FB APIs. Things I've tried include:
Attempt 1: Facebook OAuth Logout
"http://www.facebook.com/logout.php?api_key={0}&;session_key={1}";
// I don't know how to get the session key. I attempted the values stored in
// the claim "http://www.facebook.com/claims/AccessToken" but no luck
Attempt 2: ACS logout (undocumented?)
https://tlsadmin.accesscontrol.windows.net/v2/wsfederation?wa=wsignoutcleanup1.0
Neither of these approaches allow an alternate Facebook user to sign in. Any links would be appreciated.
Simplified Question
How do I get *.accescontrol.windows.net to redirect back to my website?

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 the following 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);
}

As this post suggests: Azure AppFabric Access Control Service Log Off, you can create a custom log out button, and simply call the ederatedAuthentication.WSFederationAuthenticationModule.SignOut method on the click of the button. ACS then should handle the log out process for you.

Generally speaking there are two or three steps to federated sign out - locally you need to remove the forms auth cookie if one was used as well as the FIM cookie, this will sign out from the local application.
You then need to issue wasignoutcleanup10 request to the STS used, which would sign you out from the STS itself and, in theory, shoud issue a wasignoutcleanup1.0 request (or equivalent) to all the other IPs that were involved in the process (the STS should keep track of which IPs were contacted for each request)
I built such scenario once using Windows Identity Foundation which has the components needed, but it did require some development to keep track of the all the IPs and issue the calls.
I suspect that the ACS currently does not support this behaviour meaning that a user will have to close the browser to fully sign-out from all the applications.

Related

OneLogin SSO - Multiple ACS (Consumer) URL on single SAML Application

I'm using OneLogin for Single Sign On on my application. I'd like to have a different URL to authenticate users of the mobile app (infrastructure reasons). On the OneLogin app admin page it seems I can only define one ACS (Consumer) URL, whereas on IDP's like Azure I can have multiple. Is this possible on OneLogin?
I can confirm that OneLogin does not have this feature at the moment. I'm implementing a server cluster that would utilize a single multi-san certificate and we were hoping to be able to create a single connector with OneLogin but they say that they can't provide this at the moment and the best they can do is put in a feature request to their development team.
Regards,
Hunor
Looking today I can see that there are some application configurations that support multiple ACS URLs:
If you configure a new application with one of them it is possible to list multiple ACS URLs (although I can't see a way to specify the ACS Index for each of them):
I'm not sure if it's possible to repurpose one of those configurations for a completely different service but at this stage I think it would be the only possible way as I can't find a generic Multi ACS configuration.

IdentityServer 4 with an old WebForms site

I have an old webforms site which has many business critical users using microsoft.aspnet.identity 2.2
We are wanting to extend the site, but will be using a microservice type architecture to do this. We want to spin up new .NET core services, but they need to be able to connect to this legacy database full of users. And by this I mean be able to share logins (so the user doesn't need to login twice btn the various micro services)
Is the best way to standup a IdentityServer (on its own somewhere - maybe hosted in AWS) which connects to this database and then allow:
1) The webforms to authenticate to it
2) Future .net core micro services can auth to it?
Currently we have this for our app:
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);
// Enable the application to use a cookie to store information for the signed in user
// and to use a cookie to temporarily store information about a user logging in with a third party login provider
// Configure the sign in cookie
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
SlidingExpiration = true,
CookieName = ".AspNet.SomeName"
});
// Use a cookie to temporarily store information about a user logging in with a third party login provider
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);h section
I would look at the IdentityServer4.Samples repo.
Looks like you are using OWIN, so you could easily adapt the MvcHybrid example:
https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/Clients/src/MvcHybrid
If you are not using OWIN, then have a look at the HomeController in the MvcManual client. It can easily be ported over to a WebForms app.
https://github.com/IdentityServer/IdentityServer4.Samples/blob/release/Clients/src/MvcManual/Controllers/HomeController.cs

liferay authentication from soap

I need integrate Liferay (version 6.2) with another service which stores information about users. Communication with service occurs through SOAP.
Is it possible use users from service to authenticate to Liferay?
Liferay integrates with external systems through LDAP already. If you use that interface, you're set. If you need a proprietary API to access user information, you will have some work in front of you.
It might be worth examining the SSO implementation and intercept newly authenticated users on this level: With the user's identity, create or update a Liferay user account on the fly through LIferay's API. To me this looks like the most promising approach from an effort/maintenance point of view, with the little information I have about your situation.
Alternatively you could batch-update all (Liferay-) user accounts from time to time, based on updates in your external system.
Let me see if I understand what need:
1- Step 1: User prompted with A login page.
2- Step 2: The credentials entered by the user are checked against a web service (could be any service)
3- Step 3: The user is either logged in or an auth error displayed to the user.
If that's what you need, then create an autologin hook. The code that call the webs service shall live in the autologin hook.
May seem intimidating, but it is trivial: likely liferay comes with a bunch of them: (take one of them as a template)
auto.login.hooks=com.liferay.portal.security.auth.CASAutoLogin,com.liferay.portal.security.auth.FacebookAutoLogin,com.liferay.portal.security.auth.NtlmAutoLogin,com.liferay.portal.security.auth.OpenIdAutoLogin,com.liferay.portal.security.auth.OpenSSOAutoLogin,com.liferay.portal.security.auth.RememberMeAutoLogin,com.liferay.portal.security.auth.SiteMinderAutoLogin

Adobe CQ5: SSO without LDAP?

A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html

Authenticating Users for an API Built for Third Party Application Developers

i'm in the early stages of developing an API for my site so that third party developers can build an iPhone application for it. The API would have a limited subset of the functionality of the full site. The trouble i have is around security and authentication for the user who downloads the application. I have come up with the following options:
The user enters the same credentials they use on the site to authenticate themselves. My API would then take the credentials when accessing information specific to the user. This is my least preferred solution as the third party application could log these details and use them maliciously on the full site.
Each user generates a unique key on the site which they can then use on the app to login. My API would take the api key as an argument when accessing information specific to the user. The main problem though is that any application can do what they like to the user once they gain access to their key even if the user has not given the application permission to do so.
To overcome the above problem the third party developer would have to register their application with the site and then the user would need to generate a unique key per application they wish to use. This would then be used to login. This is my preferred solution as each key is unique per application and user i can tell which application called the api and whether the user approved it.
My final option is to implement oAuth. We are currently waiting for the 2.0 version to be finalized and do not have the time to keep updating our code as the spec may change.
This is the first API i have had to build and i was wondering if i have understood this correctly? I'm assuming in option 1 the application could log the user credentials and use them maliciously but how does twitter overcome this issue with their third party applications? Or is it simply up to the user to trust the application they are using? If this is the case then would option 2 and/or 3 be feasible in the meantime until i switch to option 4.
I'd appreciate your feedback. Thanks
OAuth 1 and OAuth 2 are both viable options. But you will come a long way with basic authentication aswell (as long as it is over SSL). Don't be scared :)
I've implemented an API provider over OAuth 1.0. And since there are so many ready made libraries for OAuth1.0 for many platforms I would not be scared of using that either, much of the work has been done already, both for you as a provider and for third party implementors.
Anyway: you can always couple basic authentication with some very simple signing of the request using an application key and secret, say for example that as a third party developer you have to call.
https://yourapi.com/?user=11111&password=232123&random_string=23123&api_key=THIRD_PARTY_KEY&timestamp=1212121212signature=efefefefefef
where the API implementor has to sign perhaps the random_string, timestamp and api_key with the secret. Then you would at least have a way of shutting down malicious apps.