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.
Related
Looking for best practice instructions on how to integrate a Fiware/Wirecloud with Moodle. It would seem that Fiware/IdM should be providing the user data and Moodle connects via one of its plugins. Moodle offers a number of different authentication options (actually too many, difficult to decide best path). Ideally, once logged in, Moodle pluggins should also be able to access other FIWARE backend services.
Should be possible in principle but I notice that the Fiware academy http://edu.fiware.org/ does not have SSO with the FIWARE lab :-)
WireCloud supports using the OAuth2 token provided by the IdM to access third-party services, so the real problem is how to integrate Moodle with the IdM (as commented by #Meier).
There are some moodle plugins like auth_googleoauth2 that supposedly offer support for adding your own OAuth2 providers. Take into account that probably you will need to make more modifications to this kind of plugins as usually the OAuth provider are only used for the sign in process, but this doesn't mean that you will be able to use the OAuth2 token as valid credentials for making request to the web service API.
im am currently using a evaluation version of the PingFederate software and reading documentation all the time but still struggling to understand how i can create multiple IdPs for my SP.
I am hosting services, and setting up PingFederate as an SP. Currently in my tests i have one single IdP and all is working fine... I have set up the IIS Agent to intercept traffic and it redirects to my SP to start SP initiated SSO and that all works ok (coming in on the default startSSO url).
However, im struggling to see how i can configure the system for multiple IdP's and was wondering if someone could give a high level overview or point me at some documentation?
I understand that i have to configure the second IdP connection and i somehow need to use the PartnerIdpId URL parameter to distinguish which IdP the user is sent to.... but im not sure where i do that control/configuration for routing to different Idps? Do i need multiple agents on my IIS box that listen on different urls and can then forward the requests themselves to the right SP urls (/startSSO?partnerIdpId=XYZ) within the agent config file?
Thanks for any help,
Craig
I think your question is more around how do you trigger SP-Init SSO for multiple IDPs when using the IIS Integration Kit.
As you've figured out, as the Service Provider, you can create multiple IDP Connections (each with its own unique EntityID). You trigger SP-Init SSO by calling the /sp/startSSO.ping Application Endpoint and pass in the appropriate PartnerIdpId value that matches the EntityID of the IDP you wish to issue the AuthnRequest. You can do this one of two ways -- either hard-code the URL into the IIS Kit pfisapi.conf file so that a single entity is called each time (not the best solution) or you can manually host the URL on a page that isn't protected by the IIS Kit. Unfortunately, a lot of this design decision comes down to how your IIS application is designed and the choice of integration kit.
I would suggest talking through this with your RSA as they can help show you the pros/cons of each integration kit to match up what works best for your application & customers.
HTH,
Ian
PS
I work for Ping.
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
I would like to have some guidance regarding how to handle authentication for my restful service to be able to support a couple of different scenarios, see included image?
I've been thinking about this problem for a couple of week without finding a solution for all of the cases and even if I'll make trade offs I'll be running into problems
If we skip the Mobile application and the use of Curl, there's no need to expose the service to the public and it would be possible to use basic authentication for the server to server communication. But we'll still need to put some responsibility at the "Web site for ninjas only" to pass the (openid authenticated user) as part for the http header?
In this case we're using Google apps to manage credentials for our co-workers and I don't like the idea to manage another username/password within the service if it's possible to avoid.
Is there any sustainable solution for my dreams, so that I can build awesome features for the client and implement a tight api that manages the authorization for different resources for a specific user?
Another possible to solution might be to integrate the service with the openid provider, but then I'll have problem with passing the user from "Web site for ninjas only"
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.