I'm researching different approaches to build a web app that integrates Active Directory login into Business Catalyst. I'm wanting to implement a single sign on for active directory in an intranet environment. Specifically, users should be able to use their active directory credentials to login to Business Catalyst.
Workflow:
User provides username, password, and domain to the form.
Form sends request for authentication (I'm thinking via Soap, HTTP)
Gets a response based on the status of the AD User account (if they disabled then notify them otherwise continue)
Create a user in Business Catalyst if one is not created and login with that user. (Optionally: use a pre-existing account that has a matching username or some other matching criteria)
Optional:
detect if user is logged in with their ad account and auto-login with those credentials.
Option 1:
Communication with AD server via Liquid:
I reviewed the docs and saw the social media and the security zone docs but neither had a login api call. I know that liquid has access to server side data but I'm not sure if there is a server side call for handling authentication.
Option 2:
Build middleware that handles the Active Directory authentication and communicates the results via client-side http:
If I can’t do it through Liquid then I’m thinking I’d have to create a stand-alone service that is exposed externally (thinking node.js) and communicates between AD and client-side code via http.
Something similar to this example
https://github.com/adobebc/web-apps-sdk/tree/master/samples/bc-external-service
Additional Notes:
My active directory server is located on a machine in my intranet so the azure stuff doesn’t apply.
I know it is possible because there are products that can do this and more. I’m just not sure about all the details.
https://www.bitium.com/adobe-business-catalyst-active-directory-ad-integration
https://www.onelogin.com/connector/businesscatalyst-single-sign-on
Could you point me in the right direction to do this?
Option 1 or Option 2 or something else? Am I totally off here?
In terms of Option 1:
You can not write API with liquid markup - it is not for this. It is to render output of the BC data on the front end. It is not a server side language, its a template language basically.
Your only option is through full API, a middle-ware handling the login and interconnections.
Related
I have 3 separate net core web apps on the same IIS web server. All of them are equals at 90% but every one has its own database, its own users and its own subdomain.
I would like to have a unique web app to login into the corresponding final web app depending on the user logged, basicly because I need all the users to access from a specific URL login.my-platform.com By now every user access through its web app with a login page on its subdomain.
USER FINAL WEB APP
==================================
111 platfA.my-platform.com
222 platfA.my-platform.com
333 platfB.my-platform.com
444 platfB.my-platform.com
555 platfC.my-platform.com
Moreover, from a final web app, a user could create more users to that final web app, so the user will be accesible from the login web app.
I think an inappropriate solution would be to try to loggin to the 3 different databases changing the connectionString value and set a short connection timeout, but I want to avoid it. I think there must be a better solution and I just need a little bit of lighting. Thanks
There's two approaches:
Shared cookies
Distributed auth
The first method is available only because all of these sites share the same primary domain, i.e. my-platform.com. If that's not the case or it changes in the future, this won't work. You'll need to do two things: every site will need to be configured to use the same auth cookie name and domain (the wildcard .my-platform.com). Then, you'll need to set up a data protection provider on each that pulls from the same source. See this article for more info.
The second method, is more complicated, but also more robust. You'll need to utilize something like IdentityServer4 or a third-party service like Auth0. The former requires more code and configuration, but is free; the latter is virtually drop-in but not free and can become quite expensive, in fact, depending on your usage. In either case, your applications will connect to this distributed auth service for both authentication and authorization. For normal user login, you'd like follow an OpenID Connect workflow, where the user will be redirected to the distributed auth website to authenticate and then will be redirected back to the originating website with a token. The originating website, then, can use this token to request the user claim, and then set a cookie in the normal way.
I currently have an MVC app that's using the Microsoft.Owin.Security.WSFederation package for authentication with Azure's Active Directory. This lets me use the Authorize attribute on my controllers to redirect users to the Microsoft login site.
I now have the requirement to add access to a WebAPI project that will be hosted on a different domain but will use the same AD store.
I've managed to pull together something using the ADAL JS library provided by Azure but this gives the following process:
user visits site and is redirected to Azure login
user logs in and is returned to site
JS code checks for login and redirects to Azure
user is already authenticated so redirects back to site with token
JS picks up token, stores it, and redirects to the original page
So it works, but involves 4 redirects, which seems like a huge overhead.
I thought that there might be some way of pulling a bearer token out of the authorisation credentials returned when the WSFederation succeeds but I can't see anything like that in the data. And, even if I could, I don't know how I'd be able to then refresh the token from the client script. So I strongly suspect I'm doing something fundamentally wrong.
What would be the best process for sharing authentication between the two sites?
We made a CMS that allows users to connect to Google Analytics via a connector. I'm in the process of porting this connector to OAuth2 and am wondering what kind of application I need to register.
The issue is that the CMS is installed by our clients at arbitrary URL so we don't know the complete set of redirect URLs that I would need to register a Web Server application. Google's OAuth won't let me redirect to an arbitrary URL that I pass in during the authorization request?
Would registering an installed application and then using the urn:ietf:wg:oauth:2.0:oob special redirect URI be best? Seems like this allows the user copy/paste their authorization code from the browser back into our application.
Thanks in advance!
Indeed the installed application will allow users to copy and paste and not register. This is appropriate if the clients are end users of your application, and not say, configuring it as a plugin which will then provide web services to the client's users (where such users will then be prompted via the OAuth2 consent dialog). In the latter case you probably want to ask your clients to register their own web site as web application with Google and use a configuration tool for your CMS application to set the client's redirect URLs.
Why the distinction? Because in the first case the consent action is about your relationship with your clients, but in the latter case it expresses trust between your clients and their users. For instance, you don't want your CMS application to be disabled for abuse because one of your clients has misbehaved, as it'd affect all your clients. However, if you intermediated the consent you made it difficult for Google to understand the distinction.
I have a web based application which is used to find information about various assets in a facility. This provides only search capability, no CRUD operations allowed from the application (except for READ). This web application is always kept open in a touchscreen device (ie workstation) and this could be used by any of the facility staff. The user does not want to initiate login and logout for each of the search operation.
We are planning on deploying the web application onto the cloud. Although it is not a need to authenticate the user who is accessing the web-application, it is still a need to ensure that information about assets in the facility are not accessible by others. How do I build this authentication layer? The various options I can think of are:
1. Include userid/password in the URL as parameters. I could create a userid/password for each of the facility. Simple, but userid/password area always visible.
2. Certificate based approach. Certificates are created for each of these workstations and deployed on those workstations. Quite secure, but has the challenge of managing the certs life-cycle. As well challenge of configuring the web-servers with certs from different facilities???
Any suggestions?
Thanks,
Prasanna
A simple, but not secure thing. Do an IP check and if the IP is from your facility then grant access.
The second, but secure method is to do a verification at the start of the application with just a password and store a session , so that you will know that people from your facility are accessing the site..
I'm working on a password management system which stores the passwords of a bunch of services (gmail, bank of america account, youtube etc). The user will be able to launch each of these services by logging into my application. The application will then POST the username and password associated with that service to that service's login url in a new tab and you will be immediately logged in. My question is, this method exposes the actual password of the user to the client side (since I'm creating a form with username and password, in plain text, as hidden fields and calling form.submit). I'm wondering is there any other method by which this can be achieved? How do all the password management sites work? Your help is appreciated.
Do it server side, what else can I say? Anyway, I can only see this as a learning experience, not something that would eventually go into production. cUrl could be a good start. Why do you use form.submit anyway?
This is called "formfill" in terms of access management terminology, if you are thinking about access gateway (http). If you are thinking about browser plugin, have a look at the firefox autofill plugin. And which finally reduces to single sign-on.
Single sign-on are done different ways,-
some servers uses active directory to store all the passwords and later access using the master password , i.e. the active directory password of that user to access his credentials.
Some uses SAML
Some uses e-directory
Whatever you use, if it is server-side application (e.g. Appache supports formfill), it parses all the forms based on form name or resource path and fills credentials based on the authenticated session from the user.