I have an existing J2EE application which provides some specific features after logging in to the application.
I have to provide SSO to just ONE of the customer who logs into our application while the rest of the customers would still use the login page and login with their credentials.
I am planning to use OpenAM Fedlet act as SP deployed as a separate application in our container.
I need some help in understanding if i need a full blown OpenAM instance deployed within us. Please provide any insights if you may have on this .
You can use the fedlet as an SP for this user. The trick is identifying this particular user and initiating SSO for this person, and going to the login screen for everyone else.
Related
I have a React Application that uses Microsoft AD to authenticate users.
As a first step, and according to Microsoft Documentation, we need to register the application with the Microsoft identity platform.
This is inline with Microsoft Identity Platform Documentation, in this diagram we can see that for ALL types of applications (SPA, Web App, etc), we always need to configure an application in AzureAD:
This process is "cumbersome", and i'm trying to remove it by having the application installed automatically.
Several third-parties do this, such as Zapier, SpecFlow, etc.
Basically, they have a process where:
User logs in on Zapier
User is redirected to Azure AD sign-in page
User is authenticated and authorized
AzureAD shows the Consent Page
User consents
Application is installed on user's AzureAD
I've been reading and searching in Microsoft's Documentation, and i cannot find a single document that shows or even mentions this type of flow.
BUT, i know that this is possible, as there are several third parties that are doing exactly this, as Zapier, for example.
Can anyone point me in the right direction, there must exist some Microsoft document that explains how this process is done!
Apologies if this should be a comment, not an answer. I do not have enough SO reputation to write comments.
Zapier is published to the Azure Active Directory application gallery (1c76d9b0-0826-4b19-8706-29572657af1e). You can do this as well:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing
If an application already exists in the gallery, it does not need to be "registered" in the user's tenant, as the registration definition is defined in the gallery.
Once an app is in the gallery, users can use it only if their tenant's administrators allow this, per the settings on this page:
Enterprise applications | User settings
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/UserSettings
From the user's end, there are other governance controls that may impact the user's ability to use your app, but I think "register your app in the gallery" is probably what you're asking for.
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
I have a requirement to create an admin UI where I need to list all users registered on IdentityServer to start assigning permissions and roles. This application internally uses PolicyServer, but as a superadmin user, I would need to see all users registered on IdentityServer. Here IdentityServer is responsible for authentication and the other application that uses PolicyServer is responsible for the authorization.
Which is the correct way to proceed:
1- This admin UI application should be connected to the same database that IdentityServer uses to get all the users?
2 Or should I need to extend IdentityServer on this way?:
http://docs.identityserver.io/en/latest/topics/add_apis.html
I followed this issue here:
IdentityServer/IdentityServer3#2607
but still, it is not clear for me how to proceed on the question above.
Well, the users database is usually provided by ASP.NET Identity, not so Identity Server.
I had the same issue and I went on to develop the admin Web app in the same host as Identity Server, thus using the database connection to get to the users (and the API resources, clients, etc.).
I argue that this is the simplest way to achieve what you want. And still allows you to provide a complete API on your Identity Server for external apps. I also did that (for scenarios where client apps are allowed to view/edit the user profile, for example). The API was built using plain ASP.NET Core MVC.
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.