I am using itfoxtec-identity-saml2 library to integrate with Google Suite SSO and the library is NOT generating/calling the Saml Request Url correct:
https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXX?SAMLRequest=XXXXXXX
I think the correct should be:
https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXX&SAMLRequest=XXXXXXX
This is the Google Suite Single Sign-On Url passed to the library:
https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXX
There is any library config/parameter that I can set to fix the issue?
Please advice. Thanks
If Google Suite SSO support SAML 2.0 Authn Request with a POST binding. The problem can be solved by using the Saml2PostBinding instead of the Saml2RedirectBinding.
The Saml2RedirectBinding support a destination URL with "?" like a Google Suite SSO URL from version 3.1.0-beta2 https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/releases/tag/3.1.0-beta2.
Please let me know if the beta version works with Google Suite SSO.
* Update *
Version 4.0.0 is released supporting Saml2RedirectBinding destination URL with "?".
Related
I want to develop a Java Web App to consume some Microsoft Graph Services. According to Azure Portal's "Quick Start" tab, they recommend MSAL to authenticate and call the services (com.microsoft.aad.msal4j.*).
On the other hand, I've found https://github.com/microsoftgraph/msgraph-sdk-java-auth, which offers a nice API to use the services, but the last uptade is from more than a year.
Which should I use? I'm a bit afraid the SDK gets deprecated.
Thanks.
If you have a look at the dotnet version of this library, you'll see it uses MSAL. Whenever the Java msgraph auth library was started, MSAL Java wasn't ready. There's work that needs to be done to align the Java auth library with the dotnet one so it uses MSAL as well. I'd say go ahead and use the Java auth library keeping in mind a few things:
It will change as the required work gets done
Auth libraries for msgraph SDKs are all in preview and might change in the future
There's currently a limitation addressed by this pull request and that you can workaround as documented here
I have followed Adrian Halls book to create a cross platform app with a Mobile Service API backend. I have successfully got unsecured access to the backend working from Android, iOS and Desktop (WPF) clients. I am moving on to adding security to the API using the Authorise attribute. I would like to add social authentication using MicrosoftAccount (formerly passport/Live ID).
Since Adrian wrote his book the Microsoft.Azure.Mobile.Client and the authentication and authorisation landscape seem to have moved on. The samples given in the book no longer build and Microsoft's social authentication and AAD authentication seem to have been rolled into one API.
I have spent days searching for up to date and relevant information but there seems to be lots of stuff on the internet that is either out of date or only shows examples of authenticating using Facebook or Google from Xamarin clients or authenticating against Azure AD.
I am using .NET 4.7 and WPF for the desktop app. I am also using Microsoft.Azure.Mobile.Client V4.0.1. and my questions are:
Should I be using the Microsoft.Identity.Client to authenticate users from my desktop client; and,
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
According to your requirement, you want to use client-flow authentication with MSA. As I known, MSA authentication uses the Live SDK for signing users.
Since Live SDK is deprecated, you could leverage OneDrive SDK for CSharp for logging with MSA, and you could follow the detailed steps for achieving this purpose:
Install the client libraries via NuGet:
Microsoft.OneDriveSDK
Microsoft.OneDriveSdk.Authentication
Log into Microsoft Account Developer Center and create your app, add the native application platform, then Register your app with Microsoft Account.
Then you could follow the code below and add to your WPF application as follows:
For more details about OneDrive SDK for CSharp, you could refer to here and Authentication Adapter for the OneDrive SDK.
UPDATE:
It's my fault. I did not mention that the above code would automatically open a web browser. Per my test, you could configure the parameter returnUrl to https://login.microsoftonline.com/common/oauth2/nativeclient when constructing your MsaAuthenticationProvider instance.
I was in a similar boat - and here is summary from the top of my head - There two security libraries currently in play for authorization- ADAL, and MSAL.
ADAL
This is the first library that came out, and services like B2C must each be handle separately using this library.
MSAL
One security framework to rule them all!
https://github.com/Azure-Samples/active-directory-xamarin-native-v2
This library has a go live license, but technically it's still in Beta.
Head to Mobile.azure.com for the last info in creating a mobile application, and this article on a V2 endpoint.
When you register an application for Authorization - there are two categories a "Converged" application, and a "Live SDK application" ( see https://apps.dev.microsoft.com/#/appList) - why they would choose these names is beyond me to understand. IMPORTANT Translation - Converged application ONLY work with MSAL, the other ONLY works with ADAL. THAT will go a long way for you to get the authentication working, as the Application / Client ID must match the correct SDK, and hence endpoint.
In the end, we chose to stay with ADAL for now as we were having problems with MSAL. MSAL is the future however, as all services will be incorporated, and it should be an easier SDK to use.
Here are some links that I kept, all of which refer to ADAL or MSAL:
http://aka.ms/aadv2
https://azure.microsoft.com/develop/identity
https://learn.microsoft.com/en-ca/azure/active-directory/develop/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/AzureAD
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet
These links are about month old - HTH
The default value of the redirect URI for a new mobile app registration has a default value which is not a hierarchical URL. Using this value in the Android quick-start sample results in an invalid url exception.
The sample and the documentation require an url formatted like "https://common/oauth2/nativeclient"
The Azure Active Directory v2.0 authentication libraries docs recommend the use of a 3rd party authentication library for Android apps and this is the library used in the Quick-start sample.
Steps:
Navigate to My Applications
Add a new converged app
Add a new platform
Choose Mobile App
See that the redirect URL field is read-only and cannot be changed from "urn:ietf:wg:oauth:2.0:oob" to a hierarchical Url like the one required by the sample docs.
Update the quick-start sample file, oidc_clientconf.xml to set the value to the default value from step 5
urn:ietf:wg:oauth:2.0:oob
Compile and run the app on your Android phone. Choose Connect with Open Id and supply your credentials.
Enjoy the uncaught exception.
You're correct that for native apps you cannot change the redirect URI for v2.0 at this point. Your options are to use urn:ietf:wg:oauth:2.0:oob or https://login.microsoftonline.com/common/oauth2/nativeclient. The latter redirect uri, while not displayed in the portal, is a completely valid, pre-configured redirect uri.
For the particular sample you're looking at, it's using a 3rd party open source library that does not support the urn:ietf:wg:oauth:2.0:oob format. For this case, the alternative Redirect URI exists to allow use of other libraries that have this restriction.
Simply stick that in your sample app (or leave it in there if you're going straight off the sample) and it should not generate this exception anymore.
===========Edit==============
This answer is no longer accurate, you can set custom redirect URIs for v2.0!
I am looking for email delegation using google admin sdk.
I am using admin sdk because still its not available in Gmail API.
I checked google doc
https://developers.google.com/admin-sdk/email-settings/#delegation_examples
But it gives only feed url.
Can anyone please let me know how to call feedURl using Java code.
Or is there any api with can be used to achieve this ?
Thanks
I downloaded GmailSettingsService of package sample.appsforyourdomain.gmailsettings and modified it according to my need.
I've an app with Django as server and Angular in front end.
I know both Django and Angular have in-build support for CSRF (Cross Site Request Forgery) protection.
So from these resources:
http://django-angular.readthedocs.org/en/latest/csrf-protection.html
Django csrf token + Angularjs
I could implement CSRF protection easily.
But unfortunaltely that solutions not working for me.
More digging showed that, it won't work for Cross domains. Well, my Django and Angular will be in same domain after the build, I want to test the CSRF in my development environment.
So my question is, how can I use CSRF in cross-domain (in this scenario)? At least in my dev environment? (http://localhost/)
Thanks in advance.
I think you could simulate domain name by modifying /etc/hosts file ,
please refer to the below link for more information, it will surely solve your problem
https://docs.acquia.com/article/using-etchosts-file-custom-domains-during-development