I have downloaded onelogin saml java toolkit and its working as expected but after login it is taking to developers.onelogin.com.
Where can I set target URL to take the user after successful login?
Have you read https://github.com/onelogin/java-saml#settings?
You need to properly configure the IdP section. I guess that you used as 'onelogin.saml2.idp.single_sign_on_service.url' the developer site URL instead a real IdP SSO URL.
Related
For a particular SSO sign in that i'm trying to automate, there's be an URL that I'd need to opened in a browser, that looks like:
'https://login.microsoftonline.com/<something>/saml2?SAMLRequest=<something>&is_passive=<something>&entity_id=<something>&relay_state=<something>')
The issue I got is, with the account having multiple 2FA/MFA (2 factor / multi-factor authentication) method set up with both Microsoft Authenticator request, TOTP and FIDO2, it seems to default to the method last used in a successful log in.
What i hope to achieve is for it to automatically use the Microsoft authenticator method when this automation runs to authenticate.
I went through most pages in Microsoft website about SAML but i didn't find anything related to requesting a particular 2FA/MFA method: https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
I want to set up oAuth for a NON-google account using Chrome Identity API in my extension. I need to register my extension to get a oAuth client Id for which I need a redirected URI of the form https://<extension-id>.chromiumapp.org/<anything-here>. I am not sure what should go in the <anything-here> part of the redirected URI. The extension needs to get authentication from several websites which use their own SSO.
Turns out, the /<anything-here> part of the url doesn't even need to be there for oAuth to resolve. It can be left blank and the oAuth will still be fine.
My best guess about its usage is that, it can be used to add further information about where the request is coming from.
https://<extension-id>.chromiumapp.org/SSOMethod1
https://<extension-id>.chromiumapp.org/authfromgoogleaccount
https://<extension-id>.chromiumapp.org/id=1234556
We can now choose to handle them differently if we want to.
I have OneLogin set up for SAML authentication for my application. A functionality of my application sends out notification links to users to take certain surveys. When a user clicks on the link it takes the user to the OneLogin page for authentication. Upon successful authentication the user is redirected to the default page of the application and not the survey page which the user is supposed to work on.
Current OneLogin setup has the Consumer URL set to the default.aspx page of my application. In the web.config I have added the One Login end point connector information.
Can anything be done in the OneLogin setup to cater to the above need? Or do we need to deal with this at the application level itself. Can we set up Rules in the RULES section of my application setup in OneLogin?
To have this work properly you it sounds like you need to implement the relay state for SAML.
Essentially this value can function as a "deep link" within your application rather than the simple default page you have now.
This is usually implemented as part of SP-initiated SAML with a flow as follows
Send the user to your application - to the survey URL you want
Application doesn't have a session, starts an SP-initiated SAML flow to the provider (OneLogin) with a relay state set.
User authenticates, OneLogin does a SAML flow back to the app with the originally passed in Relay state.
Your app handles the SAML login and uses the relay state to direct the user to the original 'deep link' / relay state page.
I'm working on Xamarin.Forms application where user should Authorize using Azure AD B2C. I've managed it just fine using this library.
Now I'd like to know if it is possible to authorize without redirecting to webview. When user enters email and password on app send a get request directly to an url and receive access token, refresh token and etc. Just like in OAuth 2.0.
I've researched and found out that skipping the webview authentication part is doable but extremely not recommended for security reasons but anyway, would be glad to hear any solutions.
Webview runs on SSL (https) and hence transmission of user credentials for authentication is secured.
It’s worth noting that you don’t have to use a web view for authentication; you may create your own user interface for this flow and pass the information back to MSAL.
- this is mentioned on the same blog-post which you referred to.
All you have to do is to design your own interface and pass back the login info. It seems like a little work to do.
We have custom application which currently has a custom login page.
It integrates with Azure AD using the Oauth2 password grant type.
This works currently.
Once logged into the application, in one particular section of the website we need to embed a secure salesforce page via a iframe.
This salesforce page is setup to use oauth for the same Azure AD account - outside of the app, if we goto the salesforce page it will redirect to the azure login page (not our custom one) and we can then login and see the salesforce section (any subsequent accesses will not need the login prompt as the browser has recognised you have logged in previously)
However if we embed the secure salesforce page via a iframe, we get a
Refused to display http://xxx in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
We assume because this type of thing is not allowed with the Oauth2 spec, see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-23#section-10.13
Is it correct that the only way to have a secure salesforce page embedded on our site is to make our website a SAML provider so we can get around this specific oauth limitation?
If SAML is the way to go, how would this be implemented with this setup (struggling to find info on how to set it up like how we want) - can we keep our own login page (with some SAML specific changes) or would be forced to use the Azure login page?
The X-Frame-Options HTTP header has nothing to do with OAuth. It is a security feature that tells the browser to not load a page inside an iframe. This field is usually used to protect against clickbait attacks.
If the server responds with this header, there is usually no way to display the page in an iframe.