Currently we have a Hybrid solution where we show a web form in our Movilizer screen. This solution does not open a new browser window, but the form is shown in the movlizer screen.
This form need to be logged in with our credentials (using our login page).
Now we have a new requirement that on referring to the form, instead of our login screen, it will be redirected to a third party authentication login. Once the user is authenticated by this third party authentication, it will be redirected to the our web form.
How can we achieve this?
This must be solved first in the HTML world. Once the auth in HTML is completed (positive or negative), you can use the Movilizer specific Cordova JScript functions to provide the result to Movilizer, so the MEL logic in your Movelets can operate with it.
Movilizer runs HTML through lightweight html engines / browser components out of the frameworks of that specific platform. In other words, Movilizer clients use functionality that the native frameworks provide ... Movilizer does not have impact on how HTML itself is processed in there. Regarding the typical problems different browsers on different platforms normally bring, this means you have to carefully test the HTML part of this process on a multitude of platforms and devices.
Related
I'm enjoying developing cross-browser web extensions, the main target being Chrome, so much that I started to think to develop one for my company. I find a chrome extension quite a cheap and efficient way to deploy internal apps. The main purpose is to host a couple of dynamic dashboards that fetch data from various APIs by using cross-domain ajax in background scripts. I finalized the app and I was also able to implement the authentication via chrome.identity and Azure AD.
However, I am struggling to find a safe way to customise the content.
I mean, when the extension is installed it requires to login to azure via the chrome.identity flow. Then I get a token that I use to query ms graph and get the user ID, name, email and basic info.
Until I get this information I want the browser action (popup) to be unavailable to the user as well as any other extension pages. After a successful login I would like to show the content on the pop up and to let the user access the pages, but here I want to customize the experience.
I know how to use the user id retrieved from the api call to customize the extension, but I think it is not safe because all the code is in the client.
If I code something like
if (user === logged) show something
it will be damn easy for a malicious user to look at the code and bypass it, or even to impersonate another user. And chrome extension cannot be obfuscated.
Any help?
Thanks
We have two administrative SPAs that can make easy use of the FusionAuth templated login / verify screens. This is useful as the screens automatically reflect our social logins as those are configured,
The third SPA is carefully designed and places the login fields on a dynamic splash page. I'm considering an attempt to html embed the FusionAuth login panel on our splash page but would need to strip away the nav bar and background container. I think this would be a global change to the FusionAuth UI web layout, forcing the use of embeds in all our apps.
We have FusionAuth running on a subdomain so an embed might not cause much CORS difficulty. Are there any other reasons that embedding the login panel directly from the FusionAuth server into our pages might not be a workable solution?
You can modify the FusionAuth login UI without impacting the administration UI. If you go to Settings -> System -> UI, you will see that the Login UI templates can all be modified.
If you have different login UI elements for different Applications, you can use the variable client_id in the templates to control the layout. This is the OAuth client_id that for the FusionAuth Application. These templates are FreeMarker, so a conditional statement might look like this:
[#if client_id == 'ee31103f-2fc1-4bb5-ba95-ac543693503e']
Embeddable HTML/CSS goes here
[#else]
Standard HTML/CSS goes here
[/#if]
That being said, the OAuth login UI of FusionAuth might not be easily embeddable in your third SPA depending on if you are using an iframe or AJAX. It is still probably a better idea to skin the login UI to match your UI instead and leverage the OAuth login workflow if possible.
The other solution is to use your own login page and then call the FusionAuth APIs to authenticate the user.
We have been exploring adding an embeddable login system. If you want to open a feature request for this, you can add it on our Github Issue tracker here: https://github.com/FusionAuth/fusionauth-issues
We have a desktop application for which the user enters some registration details (e.g. support code), and can then use the application.
We would like to be able to automatically fill our support website ticket form with this information, even if the desktop application is not running.
So far we've considered:
InternetSetCookie - but it only works for Windows+IE
use Selenium to create cookies for all major browsers (seems an overkill, and required us to distribute Selenium along with our app)
have a JS service always run in the background
Are there better alternatives?
I'm curious if chrome extension overlays are delivered securely and unadulterated, and whether or not someone can "listen" to internal events.
If a user were to enter a password via a chrome extension, could I guarantee that no other browser script has recorded the password? I will hash the password with 2FA so the network request is secure, but I'm curious if anyone can get the innerHtml of an <input> within a page action.
I'm asking because I know that generally iFrames are insecure if they're hosted in an unsecure environment where they could be "replaced" with lookalike, man in the middle, phishing palettes
Thanks
Only if you injected some element into a web page it will be a part of the web page (e.g. code in an injected <script>) open to any other page script.
Internal pages and scripts of an extension like page action or toolbar popup or background page and even content script environment (variables/functions) are inaccessible from the web. With a few exceptions, you can't even directly access one from another inside your extension as those are just like different tabs/windows: messaging should be used.
The only way a web page can know what happens inside your extension is to explicitly provide it with the information from your extension. You would have to explicitly send the info via DOM messaging, for example. Or via an explicit externally_connectable mechanism.
Maybe other scripts can't record the password, however you would also need to protect the input from native components like KeyLogger, they can always get what you typed before bubbling up to browser process. So I guess a native component is also needed, it could fight with malicious keyloggers and ensure they can't get valid user input.
I am currently assessing what are the best options to integrate multiple sites to a single sign-on system. The ambition is to have a unified header with shared assets across the sites. Currently it operates as a separate login page where the user is redirected back to the page they were on before, similar to Google accounts.
There has been a proposal for an iframe or a popup iframe.
The benefits for this appear to be entirely for the user, so the user does not have to leave the page they are on. My concerns with this approach are
if we make changes to the login page itself we will need to make changes to the iframe which could require a redeployment of all the sites at the same time
the suggestion for a regular iframe is intricate to the design and will create problems across browsers
pop up iframes are problematic on mobile devices
if a user has scripting disabled they will be unable to login
a user may have a pop up blocker in place
Does anyone have any other arguments for or against using iframes for an SSO system? Any critique on the points I have already raised are also greatly appreciated.
Thanks!