How to make Google Apps iDP for Office 365 - azure

Question

I am trying to have our Google Apps users to sign in Office 365 with the Google credentials.
I am struggling with 2 things.
1. setup a federated domain with Azure AD. Can anyone match the required variables from the Google iDP Meta data below?
Below are the variables of Microsoft to set a federated domain from their help pages.
$dom = "contoso.com"
$BrandName - "Sample SAML 2.0 IDP"
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon"
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff"
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS"
$MyURI = "urn:uri:MySamlp2IDP"
$MySigningCert = #" MIIC7jCCAdag......NsLlnPQcX3dDg9A==" "#
$uri = "http://WS2012R2-0.contoso.com/adfs/services/trust"
$Protocol = "SAMLP"
Set-MsolDomainAuthentication ` -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl -SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol
This is the Google iDP metadata where it suppose to have all the info
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://accounts.google.com/o/saml2?idpid=C01gs" validUntil="2021-08-31T11:57:42.000Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDdDCCAlygAwIBAgI
MTE1NzQyWhcNMjEwODM.....yVlPqeevZ6Ij
f7LcIuZHffg1JV6pOB3A7afVp7JBbzZZOeuhl5nUhr96</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://accounts.google.com/o/saml2/idp?idpid=C02gs"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accounts.google.com/o/saml2/idp?idpid=C03gs"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
2. After a successful federated domain (I succeeded, but it didn't work, so the variables I provided powershell was wrong). The admin portal for Office 365 does NOT allow one to add users from a federated domain. So, how to add users?
Hope someone can help me with this puzzle.

Answer 1

Google now provides documentation on setting up SSO with Office 365.
Corresponding documentation on adding Google as an IdP from Microsoft is also available; however, I found no use there and kept getting failed sign-ins after following Microsoft's instructions (SSO didn't work).
Instead, I followed instructions from James Winegar which contains PowerShell commands (runnable in the Cloud Shell provided in Microsoft's admin portal, or locally) that let me get federation up and running in an hour or so, including time for user sync to start from Google's end.
This support from Microsoft seems relatively new—obviously it's less than 4 years old, based on the age of this question. But at least it now exists. By the time anyone reads this answer, there might be better tutorials available.

Answer 2

Microsoft Azure AD (the identity system behind Office 365) only support federation with a handful of Identity Federation Providers:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-federation-compatibility/
Google Apps is not in this list and is not a supported federation system. You cannot use Google Apps users to sign-in to Office 365 with their Google Apps Credentials.
What you can do however, is to allow your Office 365 users to single-sign-on to their Google Apps (which is the other way around):
https://azure.microsoft.com/en-us/documentation/articles/active-directory-saas-google-apps-tutorial/
EDIT
After the provided link, it seems that is possible to use Google Work Apps Ids for SSO with Office 365, but with the intermediate player Windows Server Active Directory and ADFS. Which quite an overhead.