@keithdv Obrigado pelo seu feedback! Iremos investigar e atualizar conforme apropriado.

@keithdv , peço desculpas pela demora em minha resposta. Eu verifiquei o thread e realmente gostaria de entender mais alguns detalhes sobre por que estamos tentando obter uma asserção SAML gerada a partir do mesmo IDP de onde planejamos buscar o token.

Prefiro ir para o fluxo de concessão de código de autorização do OAuth2.0 e obter o token de acesso. Não tenho certeza se isso deve funcionar mesmo.

Testei esse fluxo com o ADFS e funciona bem. Avise-me se desejar seguir as etapas para o mesmo, para que eu possa compartilhar com você.

Além disso, sinta-se à vontade para me informar se há um determinado requisito / restrição com base no qual você planeja seguir a rota mencionada em sua consulta, para que, munidos de um melhor entendimento sobre sua necessidade real, possamos pesquisar mais e compartilhar alguns informações mais úteis.

Oi keith,

Para obter uma declaração SAML, você precisaria ter um IDP, ou seja, provedor de identidade federado com o diretório ativo do Azure. Eu testei isso com ADFS e mais um provedor de identidade de terceiros. Qualquer IDP que suporte tokens SAML 2.0 deve funcionar com isso. Espero que isto ajude !

Obrigado
Umesh

De: Keith Voels [mailto: [email protected]]
Enviado: 21 de dezembro de 2019 02:44
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Umesh B [email protected] ; Mencione mençã[email protected]
Assunto: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

Estou tentando obter uma declaração SAML, mas tenho uma conta simples do Microsoft Azure usando meus créditos do MSDN - sem ADFS - e gostaria de tentar. Posso obter uma resposta SAML usando a API login.microsoft.com/_TenantId/SAML2?SAMLRequest, mas quando coloco a resposta SAML como a 'asserção' na chamada para 'OAuth2 / v2.0 / Token', sempre recebo um erro : AADSTS50107: O objeto de domínio da federação solicitado ' https://sts.windows.net/_TenantID_/ ' não existe. '
Como você consegue uma Asserção SAML sem ADFS?

Detalhes do Documento

⚠ Não edite esta seção. É necessário para vinculação de problemas do docs.microsoft.com ➟ GitHub.

• ID: 9f168986-8f8f-4e97-cba8-547564c97eb5
• ID independente da versão: 12ac4571-4f35-300e-9119-8d13673f3722
• Conteúdo: plataforma de identidade da Microsoft e fluxo de asserção do portador SAML https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-saml-bearer-assertion
• Fonte de conteúdo: articles / active-directory / developers / v2-saml-bearer-assertion.md https://github.com/Microsoft/azure-docs/blob/master/articles/active-directory/develop/v2-saml- bearer-assertion.md
• Serviço: diretório ativo
• Sub-serviço: desenvolver
• Login do GitHub: @umeshbarapatre https://github.com/umeshbarapatre
• Alias ​​da Microsoft: ryanwi

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWIKJA5AXT7NQUZAORTQZUYRTA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICCC32A , ou unsubscribe https://github.com/notifications/unsubscribe-auth/ AKCNYWOJY4YS73T4J7OTRWDQZUYRTANCNFSM4J6CXN2Q .

A versão 1.0 (oauth / token) faz isso.
"Asserções SAML obtidas com um fluxo OAuth2.0 OBO"
https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml -assertions-obtido-with-an-oauth20-obo-flow
Para qualquer outra pessoa ... eu ignoraria este artigo e veria o link acima.

Oi keith,

Você pode me ajudar em qual cenário deseja buscar a asserção SAML. O fluxo de asserção do portador SAML funciona com um token OAuth válido a ser apresentado a qualquer IDP para fornecer uma asserção SAML com base no mesmo. O conceito é semelhante a outras plataformas como SAP e força de vendas. O fluxo OBO é por um motivo diferente e gostaria de ter mais alguns detalhes sobre qual é o objetivo final.

@keithdv , gostaria de verificar alguns pontos:

1. Qual é a solicitação SAML e a resposta SAML que você recebeu do AzureAD?
2. Você acabou de copiar a parte da asserção ( <assertion>....</assertion> ) da resposta SAML e, em seguida, codificou o URL antes de alimentar a resposta para o ponto final de token do AAD?

Deixe-me saber as respostas para as perguntas a seguir, juntamente com o objetivo final, conforme solicitado por @umeshbarapatre, para que possamos ajudá-lo melhor.

@keithdv , tinha alguns fatos interessantes sobre este cenário. Esse processo deve funcionar apenas com domínios federados e não com um domínio gerenciado, pois a resposta compartilhada pelo IDP (no caso de um domínio gerenciado) não é confiável por esse mesmo IDP porque o domínio gerenciado não faz parte do Azure Trusted lista de domínios. Na Lista de Domínios Confiáveis ​​do Azure, apenas os domínios federados fazem parte.

Espero que isto ajude.

@ souravmishra-msft - sim, está correto. O fluxo de asserção do portador SAML é para domínios federados, ao contrário do domínio gerenciado. Por isso, perguntei o que estamos tentando alcançar aqui com este teste.

Aqui está o que precisamos. Nosso aplicativo está chamando uma API protegida e registrada do Azure AD. Essa API do Azure está, então, chamando uma API registrada e protegida do SAP. SAP é federado ao Azure AD. Não queremos que o aplicativo conheça a SAP ou ligue diretamente para a SAP.
Portanto, precisamos fazer uma troca de token dentro da API do Azure: trocar o token de portador do Azure por um token de portador SAP enquanto retém a identidade. Como dois provedores de serviço (Azure e SAP) estão envolvidos, não podemos trocar tokens OAuth2, precisamos trocar Tokens SAML - uma declaração SAML. Isso em uma API, portanto, não pode ser uma funcionalidade do navegador.
O endpoint v1 suporta isso muito bem. Você pode enviar o token de acesso da API do Azure para 'oauth / token' e obter uma declaração SAML de volta. Em seguida, enviamos a asserção SAML ao SAP e obtemos o token de acesso necessário para chamar a API SAP (consulte o link abaixo). Precisamos de um 'grant_ type: jwt-bearer ' para 'token- type: saml2 ' em V2 como existe hoje em V1.
https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow
Não estou sozinho, consulte os comentários: https://answers.sap.com/questions/12852835/sso-using-azure-ad-and-sap-netweaver.html
Eu li toda a documentação da Microsoft e nunca vi nenhuma discussão sobre “Domínios gerenciados” vs. “Domínios federados”. Não sei a que “Domínio Gerenciado” se refere.

Bem, isso é exatamente o que queríamos saber. Este artigo também foi publicado quando testamos com o mesmo cenário SAP e o artigo SAP que você mencionou ao fazer o POC. A única diferença é que, nesse cenário, o AAD e o SAP foram federados com um IDP de terceiros, ou seja, ADFS, mas pode ser qualquer outro IDP. E, portanto, sugerimos chamar o ponto de extremidade ADFS para buscar a asserção SAML. No seu caso, o AAD está atuando como IDP primário e você está chamando o terminal v1 do AAD oAuth para obter a asserção saml (podemos testar e atualizar isso como um comentário). Depois de obter a asserção SAML, você a apresenta ao ponto de extremidade do token SAP oAuth para buscar um token SAP Oauth e chamar qualquer api necessária do lado SAP também. Portanto, em poucas palavras, o fluxo de suporte permanece o mesmo. No entanto, verificarei o comentário da V1 para atualizá-lo. Isso não significa que o AAD só pode funcionar como IDP e o resto do mundo também usou muitos outros IDP, mesmo que o ADFS seja herdado. Existem muitos outros idp de terceiros que muitas empresas usam, como Oracle IDM, Vmware IDM etc. Espero que esta informação ajude!

Obrigado
Umesh

De: Keith Voels [mailto: [email protected]]
Enviado: 03 de janeiro de 2020 22:21
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Umesh B [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

Aqui está o que precisamos. Nosso aplicativo está chamando uma API protegida e registrada do Azure AD. Essa API do Azure está, então, chamando uma API registrada e protegida do SAP. SAP é federado ao Azure AD. Não queremos que o aplicativo conheça a SAP ou ligue diretamente para a SAP.
Portanto, precisamos fazer uma troca de token dentro da API do Azure: trocar o token de portador do Azure por um token de portador SAP enquanto retém a identidade. Como dois provedores de serviço (Azure e SAP) estão envolvidos, não podemos trocar tokens OAuth2, precisamos trocar Tokens SAML - uma declaração SAML. Isso em uma API, portanto, não pode ser uma funcionalidade do navegador.
O endpoint v1 suporta isso muito bem. Você pode enviar o token de acesso da API do Azure para 'oauth / token' e obter uma declaração SAML de volta. Em seguida, enviamos a asserção SAML ao SAP e obtemos o token de acesso necessário para chamar a API SAP (consulte o link abaixo). Precisamos de um 'grant_ type: jwt-bearer ' para 'token- type: saml2 ' em V2 como existe hoje em V1.
https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow
Não estou sozinho, consulte os comentários: https://answers.sap.com/questions/12852835/sso-using-azure-ad-and-sap-netweaver.html
Eu li toda a documentação da Microsoft e nunca vi nenhuma discussão sobre “Domínios gerenciados” vs. “Domínios federados”. Não sei a que “Domínio Gerenciado” se refere.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWLXEV5ME6XAZFPST6TQ35UJDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBR5VQ#issuecomment-570629846 , ou unsubscribe https://github.com/notifications/ unsubscribe-auth / AKCNYWJUJ7FN6NV43FM2D2DQ35UJDANCNFSM4J6CXN2Q .

Com licença, mas as explicações aqui não me tornaram realmente mais inteligente. Estou um pouco confuso agora, então seria ótimo se alguém explicasse um pouco mais sobre o que precisa ser feito.

Configurei o SSO entre o Azure Active Directory e a SAP Cloud Platform. Depois de fazer logon no SAP Cloud Platform por meio do Azure AD, recebo uma resposta SAML. Eu criptografo a parte de asserção da resposta SAML com BASE64. Em seguida, envio isso para o ponto de extremidade do token (v2). Lá eu também recebo a mensagem de erro 'AADSTS50107: O objeto de domínio da federação solicitado' https://sts.windows.net/_TenantID_/ 'não existe'.

Foi encontrada uma solução para isso? Ou estamos basicamente fazendo algo completamente errado?

@noirde você está perto. Você está no mesmo caminho que eu. Na verdade, não consegui experimentar a Asserção SAML do Azure com SAP em minha empresa, estou aguardando acesso. Assim que o fizer, temo cometer o mesmo erro. Você obtém o mesmo erro ao tentar usar a asserção SAML com o Microsoft Graph. Veja os comentários fechados sobre o erro.
Se eu tiver permissões, direi se formos bem-sucedidos ou não.

Oi keith,

Você pode compartilhar o envelope de declaração de amostra que está recebendo ao fazer uma chamada para o ponto final do azure v1. Isso é uma afirmação de envelope Samlp?

Obrigado
Umesh

De: Keith Voels [mailto: [email protected]]
Enviado: 06 de janeiro de 2020 08:58
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Umesh B [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

@Noirde https://github.com/Noirde você está perto. Você está no mesmo caminho que eu. Na verdade, não consegui experimentar a Asserção SAML do Azure com SAP em minha empresa, estou aguardando acesso. Assim que o fizer, temo cometer o mesmo erro. Você obtém o mesmo erro ao tentar usar a asserção SAML com o Microsoft Graph. Veja os comentários fechados sobre o erro.
Se eu tiver permissões, direi se formos bem-sucedidos ou não.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWMSMKAXIUX3T2CF7BTQ4KQNDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEJYAI#issuecomment-570989569 , ou unsubscribe https://github.com/notifications/ unsubscribe-auth / AKCNYWOPER7HLDULIQQHV63Q4KQNDANCNFSM4J6CXN2Q .

Oi Umesh,
Aqui está. Eu não acredito nisso. É simplesmente <Assertion>

<Assertion ID="_32e7b830-43cf-40cd-a0f7-0ddf851dfb00" IssueInstant="2020-01-06T22:03:57.551Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer>https://sts.windows.net/cb632b2c-217b-4edd-9be9-35f29b5c9f11/</Issuer> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference URI="#_32e7b830-43cf-40cd-a0f7-0ddf851dfb00"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>Ng1WJ0mjixtBOAflWvZUX10duf7bmjHV7DGIyQDiABs=</DigestValue> </Reference> </SignedInfo> <SignatureValue>BbHkH/aXuejrSDoWHuBXbXWVyF8aU1O1ZMtCaJwgvrvjBjuA8Go9P7y+maryiQXk0+o/6jv5GciNkYaatAcIl8XpHetUvs6VRtEbqleE0n80LY/eSV7fDmhRYnq7YlH/d3lEmMInsEE2q0WxX/9hxvpADlTt6x1zF7QvCSmQl5nlBEvYuPXqhKgLNtCbBykwu+CHHfcP+ULBJZkZJp12wbV00yPJxlrOYSvszKLmvwaBqWNqxjmuKUADNnHnbHZWr2UbsuBiBn2fIOTg6AFhl7JktI/vMMr35wJJkJTDWvq8CknJxFHxGKUspCGHtI0nNOCUhBaiCw3q4LcKylpOlw==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIDBTCCAe2gAwIBAgIQMCJcgWf4l5xPpeoEwB7DKDANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTE5MTExNTAwMDAwMFoXDTI0MTExNDAwMDAwMFowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANF4YcKZhKTfowwWqZ84RW7bxFNgaSy3Gi85V5uJpU9jMCmZV0VFGptryNFEQ1GESmmuDutgQlkkhjr9ixkOrTA+aFPg6pLn+OG6NYS7nyKgAC1MprLH0bq06y3dH6lQPWQhd3wPP+8UIua9+9JuIfhu9Xs/HhN5cYlT5cEniV0aWuUMxgPAKcG1xolfupYhlOHjFwVN/QOaxcuk3YqGguD+sZ7PiHcJSzFnTkdvD+DtMoW1U6nDf5FuDeAEKJ7JQf7RjiRoViYxZHKrEPHG4iZ+kOhV6DQA16ISTt7ALXVB8gTTF3OvItubk2E3v6sgirgtvdE5Mkd4MTJcO67bgdUCAwEAAaMhMB8wHQYDVR0OBBYEFEXiTeLGkA2LgAjQOrT2KChpgwCgMA0GCSqGSIb3DQEBCwUAA4IBAQA6GqtYZDQzym0yxfL2NnlSbJP/lLhSQOqbPBdN6DWQ/3duk+e08Ix5qy63hzW+qQR0PAkFEcooL5+bdheS66tFJpVejEcqCSKUVvwOUe6GY/ju752dlB7anBB9An362khehCxqydYNS5Igl0rtcP7dKC3ZBn1m2B9ULsyx46iNpfHQHHv9NKU2vVq2CtNc95CFktwjUwlyWMgbfI/DzPX/cC6KnglqsuVVBO7+jIaBmi0XGqudooZkqgIrvnfNMM13Gy78TUNHsCiAQEwZ/L17yNbzotNGxAoPfuXldbD52MQNOsA7WhH+j8qFWY6gZzTN4NpVtuW4m04TCEFexnTz</X509Certificate> </X509Data> </KeyInfo> </Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ftOmbYBIMVgi3RWFQa2lLAqkmtzBAdZXJjrcQVo5KR0</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> </Subject> <Conditions NotBefore="2020-01-06T21:58:57.207Z" NotOnOrAfter="2020-01-06T23:03:27.207Z"> <AudienceRestriction> <Audience>https://ebs.sap.com/sap/bc/sec/oauth2/token</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid"> <AttributeValue>cb632b2c-217b-4edd-9be9-35f29b5c9f11</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier"> <AttributeValue>af56d9be-a146-4230-801e-f83f1a3bab4e</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"> <AttributeValue>Voels</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"> <AttributeValue>Keith</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname"> <AttributeValue>Keith Voels</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider"> <AttributeValue>live.com</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences"> <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue> <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified</AttributeValue> </Attribute> </AttributeStatement> <AuthnStatement AuthnInstant="2020-01-06T22:03:07.208Z"> <AuthnContext> <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion>

O meu é um pouco diferente. Especialmente o provedor de identidade para mim não é live.com, mas também sts ... /. Seguido este tutorial - https://developers.sap.com/tutorials/cp-azure-ad-saml.html.

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_718927ef-7105-4baa-84c5-74b8b0b46600" IssueInstant="2020-01-07T09:22:48.487Z" Version="2.0" > <Issuer>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</Issuer> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> <Reference URI="#_718927ef-7105-4baa-84c5-74b8b0b46600"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <DigestValue><Value></DigestValue> </Reference> </SignedInfo> <SignatureValue><Value></SignatureValue> <KeyInfo> <X509Data> <X509Certificate><Value></X509Certificate> </X509Data> </KeyInfo> </Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"><Value></NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InResponseTo="a883788fahf73ai48ee64e660g4fe8" NotOnOrAfter="2020-01-07T10:22:48.268Z" Recipient="<value>" /> </SubjectConfirmation> </Subject> <Conditions NotBefore="2020-01-07T09:17:48.268Z" NotOnOrAfter="2020-01-07T10:22:48.268Z" > <AudienceRestriction> <Audience>https://<Value>.authentication.eu10.hana.ondemand.com</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid"> <AttributeValue>32b337ff-9459-4bc1-b28a-b720735cbe39</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier"> <AttributeValue>113b9583-05a6-4867-90f2-1ab4d1ef7225</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider"> <AttributeValue>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences"> <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue> </Attribute> <Attribute Name="first_name"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="last_name"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="mail"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="Groups"> <AttributeValue><Value></AttributeValue> </Attribute> </AttributeStatement> <AuthnStatement AuthnInstant="2020-01-07T09:22:46.413Z" SessionIndex="_718927ef-7105-4baa-84c5-74b8b0b46600" > <AuthnContext> <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion>

Obrigado Keith. Algumas perguntas. Esta afirmação é aceita no token sap oauth. Não consegui ver o nome que posso estar lendo.
De dispositivo móvel, mas esse é um dos
O atributo obrigatório. Avise-me se pudermos nos conectar algum dia

Obtenha o Outlook para iOS https://aka.ms/o0ukef

De: Keith Voels [email protected]
Enviado: terça-feira, 7 de janeiro de 2020 3:39:53
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Umesh B [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

Oi Umesh,
Aqui está. Eu não acredito nisso. É simplesmente

https://sts.windows.net/cb632b2c-217b-4edd-9be9-35f29b5c9f11/ Ng1WJ0mjixtBOAflWvZUX10duf7bmjHV7DGIyQDiABs =BbHkH / aXuejrSDoWHuBXbXWVyF8aU1O1ZMtCaJwgvrvjBjuA8Go9P7y + maryiQXk0 + O / 6jv5GciNkYaatAcIl8XpHetUvs6VRtEbqleE0n80LY / eSV7fDmhRYnq7YlH / d3lEmMInsEE2q0WxX / 9hxvpADlTt6x1zF7QvCSmQl5nlBEvYuPXqhKgLNtCbBykwu + CHHfcP + ULBJZkZJp12wbV00yPJxlrOYSvszKLmvwaBqWNqxjmuKUADNnHnbHZWr2UbsuBiBn2fIOTg6AFhl7JktI / vMMr35wJJkJTDWvq8CknJxFHxGKUspCGHtI0nNOCUhBaiCw3q4LcKylpOlw ==MIIDBTCCAe2gAwIBAgIQMCJcgWf4l5xPpeoEwB7DKDANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTE5MTExNTAwMDAwMFoXDTI0MTExNDAwMDAwMFowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANF4YcKZhKTfowwWqZ84RW7bxFNgaSy3Gi85V5uJpU9jMCmZV0VFGptryNFEQ1GESmmuDutgQlkkhjr9ixkOrTA + aFPg6pLn + OG6NYS7nyKgAC1MprLH0bq06y3dH6lQPWQhd3wPP + 8UIua9 + 9JuIfhu9Xs / HhN5cYlT5cEniV0aWuUMxgPAKcG1xolfupYhlOHjFwVN / QOaxcuk3YqGguD + sZ7PiHcJSzFnTkdvD + DtMoW1U6nDf5FuDeAEKJ7JQf7RjiRoViYxZHKrEPHG4iZ + kOhV6DQA16ISTt7ALXVB8gTTF3OvItubk2E3v6sgirgtvdE5Mkd4MTJcO67bgdUCAwEAAaMhMB8wHQYDVR0OBBYEFEXiTeLGkA2LgAjQOrT2KChpgwCgMA0GCSqGSIb3DQEBCwUAA4IBAQA6GqtYZDQzym0yxfL2NnlSbJP / lLhSQOqbPBdN6DWQ / 3duk + e08Ix5qy63hzW + qQR0PAkFEcooL5 + bdheS66tFJpVejEcqCSKUVvwOUe6GY / ju752dlB7anBB9An362khehCxqydYNS5Igl0rtcP7dKC3ZBn1m2B9ULsyx46iNpfHQHHv9NKU2vVq2CtNc95CFktwjUwlyWMgbfI / DzPX / cC6KnglqsuVVBO7 + jIaBmi0XGqudooZkqgIrvnfNMM13Gy78TUNHsCiAQEwZ / L17yNbzotNGxAoPfuXldbD52MQNOsA7 WhH + j8qFWY6gZzTN4NpVtuW4m04TCEFexnTzftOmbYBIMVgi3RWFQa2lLAqkmtzBAdZXJjrcQVo5KR0 https://ebs.sap.com/sap/bc/sec/oauth2/token cb632b2c-217b-4edd-9be9-35f29b5c9f11af56d9be-a146-4230-801e-f83f1a3bab4eVoelsKeithKeith Voelslive.comhttp://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/passwordhttp://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified urn: oasis: names: tc: SAML: 2.0: ac: classes: Password

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWICCZVPVAWOMG5QTI3Q4OT3DA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIG6VLA#issuecomment-571337388 , ou unsubscribe https://github.com/notifications/ unsubscribe-auth / AKCNYWN7ATHP2NQHI3NUYHTQ4OT3DANCNFSM4J6CXN2Q .

Em relação ao post de Keith, háftOmbYBIMVgi3RWFQa2lLAqkmtzBAdZXJjrcQVo5KR0 .

Acho que Keith está fazendo algo bastante semelhante a mim, mas de alguma forma contra a v1 e não a v2. Para o teste, aproveitei a afirmação que recebi depois de fazer login com êxito no SAP Cloud Platform por meio do Azure AD. Eu o transformei em base64 via https://www.base64encode.org/ manualmente.

Agora estou tentando postar em " https://login.microsoftonline.com/ {{TenantID}} / oauth2 / v2.0 / token" com o corpo:
grant_type:urn:ietf:params:oauth:grant-type:saml2-bearer client_id:{{ClientID}} client_secret:{{ClientSecret}} scope:https://graph.microsoft.com/.default assertion:{{Base64_encoded_assertion}}

Agora estou recebendo o erro mencionado:
{ "error": "invalid_request", "error_description": "AADSTS50107: The requested federation realm object 'https://sts.windows.net/<tenantId>/' does not exist.\r\nTrace ID: 6365a830-7aa3-4b27-94cc-7b3d31d09a00\r\nCorrelation ID: 5f89f618-58d2-4f4a-9e90-fcf3d7ca6762\r\nTimestamp: 2020-01-10 17:24:49Z", "error_codes": [ 50107 ], "timestamp": "2020-01-10 17:24:49Z", "trace_id": "6365a830-7aa3-4b27-94cc-7b3d31d09a00", "correlation_id": "5f89f618-58d2-4f4a-9e90-fcf3d7ca6762", "error_uri": "https://login.microsoftonline.com/error?code=50107" }

@noirde Encontrei esse erro várias vezes e não o consegui contornar. Não consigo fazer com que o Microsoft Graph aceite uma Asserção SAML para obter um token de acesso em qualquer cenário.

@umeshbarapatre Sim, conseguimos que o SAP aceitasse a

Sim, gostaria muito de me conectar. Por favor me envie um email. Obrigado!

Alguma atualização ou mais dicas?

Oi keith,

Desculpe, mas fiquei um pouco ocupado com as responsabilidades do dia a dia. Com qual fuso horário você está trabalhando. Podemos nos conectar pelo skype na terça-feira, 4 de fevereiro.

Obrigado
Umesh

De: Keith Voels [mailto: [email protected]]
Enviado: 21 de janeiro de 2020 03:14
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Umesh B [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

@Noirde https://github.com/Noirde Eu encontrei esse erro várias vezes e não o consegui contornar. Não consigo fazer com que o Microsoft Graph aceite uma Asserção SAML para obter um token de acesso em qualquer cenário.

@umeshbarapatre https://github.com/umeshbarapatre Sim, conseguimos que o SAP aceitasse a declaração SAML. Tivemos que brincar com o atributo NameID, AudienceRestriction e Recipient nas configurações do Aplicativo Corporativo do Azure, mas conseguimos fazer funcionar.

Sim, gostaria muito de me conectar. Por favor me envie um email. Obrigado!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWOEA27GFBJVMY62W5TQ6YLKPA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJN4FIA#issuecomment-576438944 , ou unsubscribe https://github.com/notifications/ unsubscribe-auth / AKCNYWMYS3GU3G5LFK3URCLQ6YLKPANCNFSM4J6CXN2Q .

Você conseguiu deduzir uma solução?

@keithdv - É bom saber que NameID e outros atributos funcionaram para você. API de Graph Wrt, se você pode dizer qual API de gráfico você está usando, então provavelmente posso compartilhar minhas opiniões, o que pode ser útil.

Você conseguiu deduzir uma solução?

@Noirde - Como Keith confirmou que a declaração SAML foi bem-sucedida, estamos um passo à frente, posso ajudar com a aceitação do Graph API com base nas informações fornecidas

@umeshbarapatre - Eu tenho um cenário de autorização diferente e estou tentando determinar se posso usar SAML Assertion para fluxo de token de portador OAuth2 ou se este thread está dizendo que não funcionará. No meu caso, estou usando SAML2 SSO para aplicativo de terceiros com AzureAD como o IdP ... isso está funcionando, mas quero obter um token de portador OAUTH para chamar o gráfico da Microsoft (mesmo locatário do AzureAD) para integrar o aplicativo de terceiros ao Office 365. Ainda estou trabalhando no teste, mas este tópico me deixou confuso se isso deveria ou não funcionar. Qualquer ajuda é apreciada.

Portanto, cheguei ao ponto em que a asserção SAML emitida pelo Azure AD é aceita por login.microsoftonline.com/tenant-id/OAuth2/v2.0/token, mas recebo o mesmo erro que você:

AADSTS50107: O objeto de domínio da federação solicitado ' https://sts.windows.net/tenant-id/ ' não existe.

Estou pedindo o seguinte tipo de concessão: ' urn: ietf : params: oauth : tipo de concessão: saml2-portador ' para acessar a API Graph no mesmo domínio da Asserção SAML.

Quando eu executo esta consulta em nosso locatário do PowerShell:
Get-MsolDomainFederationSettings
o resultado está vazio.

Vários artigos de fornecedores, como este da SecureAuth:

https://support.secureauth.com/hc/en-us/articles/360019646672-O365-Error-Message-AADSTS50107-Requested-federation-realm-object-does-not-exist

implica que o Emissor precisa aparecer na saída deste comando?

@Khyzdul Eu nunca fiz a API do Microsoft Graph aceitar uma declaração SAML conforme documentado. Eu fiquei preso no erro em que você está. No Azure, use tokens OAuth2.

O que conseguimos foi que outros fornecedores (MuleSoft, SAP) aceitarão a Asserção SAML do Azure para obter tokens de portador OAuth2 específicos do usuário.

Para mim, isso é lógico. OAuth2 não se destina a envolver mais de um provedor de identidade. SAML é; esse é o seu papel. Portanto, ao pular os provedores de identidade, use uma asserção SAML. Dentro de um único provedor de identidade, não use Asserções SAML.

@keithdv Embora seja verdade o que você diz sobre a diferença em SAML e OAuth2, existem dois outros aspectos, eu acho. Um é o fato de que o SAML é usado para alguns sistemas legados mais antigos que ainda não implementam o OAuth na parte traseira (e seria bom ser capaz de reutilizar essa parte e usar a asserção para outras coisas) e, segundo ( e mais importante (imho), alguém poderia / poderia supor que, ao solicitar uma declaração SAML de "um locatário AAD" e, posteriormente, obter um token do mesmo locatário AAD não exigiria qualquer federação? Eu entendo o motivo técnico pelo qual recebemos esse erro, mas do ponto de vista lógico / do usuário, não faz muito sentido ... você não concorda? (agora está basicamente dizendo "não confiamos em nossos próprios domínios")

@Khyzdul - Posso saber se há uma necessidade específica de usar a rota SAML no seu caso. Eu entendo que você está federado apenas no Azure. você pode chamar diretamente o ponto de extremidade do token OAuth para obter um token, a menos que haja algo que esteja faltando

@Khyzdul é principalmente uma questão de "o que já temos". Temos um produto bastante grande que já possui SAML Integrado para o procedimento de login e funciona com AAD.

No entanto, outro (novo) módulo / extensão / plug-in precisa acessar o MS Graph SDK e podemos dar a ele a asserção, mas na verdade ele precisa "trocar" isso por um token (isso não é visível para o usuário então) e chame a função Graph. Isso não é possível agora, porque o AAD que vem com o O365 e faz SAML não pode transformá-lo em um token por causa do erro de que o Realm não é conhecido (mesmo que seja o mesmo AAD).

Portanto, agora você pode realmente argumentar que poderíamos reescrever todo o procedimento de login com OAuth, mas isso é uma quantidade razoável de trabalho em um produto legado. Isso tem impacto no produto porque, até agora, era apenas um módulo que precisava ser alterado, e agora de repente se torna uma alteração séria do produto, para contornar algo que do ponto de vista do usuário é definitivamente um "bug". Assim, impacto no roteiro, ciclos de controle de qualidade, lançamentos, etc ...

@keithdv Temos exatamente o mesmo requisito, obtenha a declaração SAML do AAD, use-a para enviar ao SAP um token de acesso e chame a API SAP usando o token de acesso. Eu li toneladas de documentos e ainda não consigo fazer funcionar. Pelos comentários acima, parece que o seu está funcionando agora. É possível que você possa compartilhar as etapas? Muito obrigado.

Testamos nossa teoria de que precisávamos registrar nosso inquilino como um reino de federação confiável com ele mesmo (fez isso em um inquilino de não produção). A mensagem de erro resultante indicou que tínhamos que definir o modo de autorização do locatário para federação.

Nossa conclusão neste ponto é que teremos definido o locatário em um modo em que ele espera que sua autenticação seja tratada por um IdP externo. Sem saber qual pode ser o efeito colateral de coisas como o O365, não vamos prosseguir com isso. Estamos reescrevendo o aplicativo para usar Oauth.

Estou perplexo com a lógica de oferecer suporte ao SSO SAML (usando o Azure AD como IdP), se o Azure AD não confiar nas afirmações que ele emite.

Seria útil se a MS publicasse um guia de SSO do Azure AD ilustrando os padrões aos quais eles oferecem suporte e destacando claramente as suposições / limitações de cada um. Por exemplo, se você usar SAML com o Azure AD como IdP, não poderá usar a sessão para chamar a API de gráfico porque a troca de token não é compatível.

Parece ser um motivo para evitar completamente o uso do Azure AD como um IdP SAML.

Obrigado pela conversa envolvente.

Obtenha o Outlook para Android https://aka.ms/ghei36

De: dominic1904 [email protected]
Enviado: quarta-feira, 6 de maio de 2020 7:55:13 AM
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Khyzdul [email protected] ; Mencione mençã[email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Como obter uma declaração SAML sem ADFS (# 45071)

@keithdv https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeithdv&data=02%7C01%7C%7Ce4937829995f44b2fc3108d7f1b4566f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637243629152039847&sdata=SSCEzWzXsqKX4DeDTAVKZ4VEK5AoUsjXo4Wu8LF%2BnTM % 3D & reserved = 0 Temos exatamente o mesmo requisito, obtenha a declaração SAML do AAD, use-a para enviar ao SAP um token de acesso e chame a API SAP usando o token de acesso. Eu li toneladas de documentos e ainda não consigo fazer funcionar. Pelos comentários acima, parece que o seu está funcionando agora. É possível que você possa compartilhar as etapas? Muito obrigado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F45071%23issuecomment-624605575&data = 02% 7C01% 7C% 7Ce4937829995f44b2fc3108d7f1b4566f% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% & 7C637243629152049843 sdata = 8jUZhFplYEqm5mKPusLYAqtZxY4p3gMyMjHYQs7tSQM% 3D & reservados = 0 , ou de cancelamento https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. COM% 2Fnotifications% 2Funsubscribe-auth% & 2FAO5BDHYDRYGUG735YX7JQG3RQFF2DANCNFSM4J6CXN2Q dados = 02% 7C01% 7C% 7Ce4937829995f44b2fc3108d7f1b4566f% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% & 7C637243629152049843 sdata = Xzy8% 2F7HUCgMjDJgKSdhyPqifGxI% 2BS3Jes2GSbOEHwPU% 3D & reservados = 0 .

Há alguma atualização sobre este tópico?

Estou exatamente na mesma situação. Registrei um SAP C4C Enterprise Application no AAD e posso usá-lo com sucesso para Single Sign On to SAP.

Além disso, quero usar exatamente o mesmo aplicativo AAD para solicitar uma asserção SAML do AAD e usá-lo como um portador SAML OAuth para solicitar um token de acesso do SAP. Como @keithdv mencionou no início desta edição, também posso receber uma declaração SAML do endpoint login.microsoft.com/_TenantId/SAML2 mas não tenho absolutamente nenhuma ideia de como posso influenciar o Recipient de SubjectConfirmation na resposta SAML para corresponder ao endpoint de token SAP desejado: .../sap/bc/sec/oauth2/token .

Para esclarecer minha situação:

Tenho um cliente que deve ser capaz de realizar solicitações a uma API SAP privada. Portanto, os usuários devem fazer login em seu AAD que já tenha uma relação de confiança com seu SAP. Deste ponto em diante, gostaria de receber uma asserção SAML do AD com o ponto de extremidade do token SAP como recipient que posso usar com minhas outras credenciais do aplicativo OAuth do SAP para obter um token de acesso. Ainda não tenho certeza se isso é possível com o Azure devido a todas as diferentes declarações nesta edição e diferentes outras fontes mencionadas aqui. Eu realmente apreciaria qualquer conselho sobre isso.

reatribuir: paulgarn @paulgarn Cc: @hpsin

O usuário umeshbarapatre do GitHub foi removido da organização MicrosoftDocs, portanto, ele foi removido automaticamente como um responsável.

Redirecionando o problema # 59746 aqui.
CC: @ amit17051980

Obrigado Krish.
Estou esperando ansiosamente por uma solução!

Foi confirmado pela equipe do produto que sim, essa troca é especificamente para usuários federados em que o aplicativo obtém um token SAML do ADFS ou outro IDP federado. Não há planos para adicionar mais funcionalidades neste momento.

Na maioria dos casos, este cenário (onde o usuário é um usuário AAD e o token SAML que você possui é emitido do AAD com o aplicativo como Público) pode ser satisfeito por um fluxo de código de autenticação regular. Basta obter um código de autenticação do AAD e solicitar um token de acesso para o gráfico do terminal do token. Uma vez que o usuário já está conectado (para obter o token SAML). O SSO entra em ação e nenhuma reautenticação é necessária do usuário. O resultado final é o mesmo.

Continuaremos para encerrar este problema agora. Sinta-se à vontade para comentar aqui se houver alguma dúvida ou problema de acompanhamento.

@ krish-gh Portanto, não há planos para adicionar funcionalidade que está na v1.0 do terminal de token (link abaixo) ?? Novamente, isso é CRÍTICO para nosso fluxo de trabalho nos comunicarmos com SAP e Salesforce e teremos grandes problemas se essa funcionalidade for eliminada. Já estamos na camada de serviço em muitas camadas físicas além do navegador.

A versão 1.0 (oauth / token) faz isso.
"Asserções SAML obtidas com um fluxo OAuth2.0 OBO"
https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml -assertions-obtido-with-an-oauth20-obo-flow

Aqui está um diagrama do que precisamos realizar. Somos a equipe da API de integração - não podemos pedir ao aplicativo do navegador para fazer alterações. Na verdade, não queremos que eles resolvam se é que a SAP está atendendo à solicitação. Novamente, podemos fazer isso com o ponto de extremidade do token OAuth2 v1.0.
SAP OBO.pdf

@keithdv continue com a v1.0 em sua parte de asserção OBO SAML do fluxo de trabalho da API. Não há planos de retirá-lo da v1.

Conforme mencionado, não há nenhum plano imediato para adicionar isso na V2 ainda. Manteremos a marca na demanda desse cenário. Muito obrigado por compartilhar os detalhes do seu fluxo de trabalho.