During a AuthnRequest, is there a case where the AudienceRestriction
<saml:AudienceRestriction>
<saml:Audience>http://serviceprovider.com/</saml:Audience>
</saml:AudienceRestriction>
would be different from the Issuer in the AuthnRequest
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://serviceprovider.com/acs/web/sso/receiveSamlAuthentication"
Destination="http://idp.net/idp/SSOPOST/metaAlias/realm2/IDP"
ID="http://serviceprovider.com/acsdata/data/AcsConfiguration/821212" IssueInstant="2010-08-20T14:48:27.620Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://serviceprovider.com/</saml2:Issuer>
....
</saml2p:AuthnRequest>
The SAML 2.0 Web Browser SSO Profile (from saml-profiles-2.0-os.pdf:566/577):
The assertion(s) containing a bearer
subject confirmation MUST contain an
AudienceRestriction including the
service provider's unique identifier
as an Audience
So, it seems as though it should always be the case that they are the same, at least to be conformant to the published profile.
Perhaps if you have one login application at one URL, and a "real" application at a different URL? Maybe not common, but hardly impossible; say, having login functionality over HTTPS and the application over HTTP.
Related
I am new to KeyCloak, and am trying to configure it as a SAML IDP to a SalesForce client.
IDP initiated SSO flow works fine. I am directed to the Salesforce home page correctly post-authentication. However, SP initiated SSO gives me a JSON output instead of the Keycloak login page.
This is the URL that SalesForce is redirecting to (masked IP):
http://10.99.xxx.xxx:8080/auth/realms/test?SAMLRequest=...
SAML tracer indicates a valid SAML authentication request.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://f-corpcont--dev.my.salesforce.com?so=00D3K000000lOS"
Destination="http://10.99.xxx.xxx:8080/auth/realms/test"
ID="_2CAAAAXJxZQlkME8wswMDAwMDAwMDA2AAAA3kJle3T1o4lEOE9QztKYIVXwLjlHOcfEaw-7mLWvYqmEiPv5SS32lT0WcQIbjXTP-qO779xPjACwqlhiGs9ZM8ZmltHZd6stzimY1Br3b1_5PqBgWxExV7R1FAAxZ914_3s8rViWWGxmKKGFN94OG2WBh3SMPF3WwGagDIZLRKtSpcGIDCGkuYERb_DR0LgOflx-C0kF7XqKdtU8OTTbk0HpoCKQ8oRh58Mai1eFlqgKf50rdGsFQmCQa-Sg0-JyZg"
IssueInstant="2020-05-04T19:39:22.807Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://f-corpcont--dev.my.salesforce.com</saml:Issuer>
</samlp:AuthnRequest>
The JSON output I see in my browser is:
{
"realm": "test",
"public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqHobhU5mQ2itvVfkDWm64sLgT9dfoCNm137ul+A7YRNSXk5g0JEGxoZLVdicRQUx0mr4z6BEM+LN/mztSsigG0aQIqUY8y1un33kBk5gE6W3jaFDX6Rsap/lcXIoO7Jl/pzjAxf3R8RyMMhFQ4Hi1rHl2wSXMWfeNLaoLrzy+LEG1KNZpfhbfG1HUa5fEYpI0sSWEEgcP3faEy2JWOJrfJrcS1tezDD+7x4u+fTUJt0M8vsIjMDAX9UUu+JXnG901a15drj9UjYJyiMJTFQt3Rdrxv96XZa93fKyB36an5GDZWPiwEehtjAJ4mQ0oo0v/TmevoJwZd7YTvClQIDAQAB",
"token-service": "http://10.99.xxx.xxx:8080/auth/realms/test/protocol/openid-connect",
"account-service": "http://10.99.xxx.xxx:8080/auth/realms/test/account",
"tokens-not-before": 0
}
Any pointers would be appreciated
You have used wrong URL for SAML request. Wrong:
http://10.99.xxx.xxx:8080/auth/realms/test?SAMLRequest=
Correct:
http://10.99.xxx.xxx:8080/auth/realms/test/protocol/saml?SAMLRequest=
I am trying to enable SSO capabilities for Apache Zeppelin, using Apache Knox, which is configured to redirect auth requests to a Siteminder IdP.
The issue I am having is related to the NameID format configuration, and the signing configuration.
No matter what I configure in the sp/idp metadata, the NameID format used is
urn:oasis:names:tc:SAML:2.0:nameid-format:entity
And the requests are always being sent with Signed requests set to true.
My SP configuration is as follows:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client">
<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol http://schemas.xmlsoap.org/ws/2003/07/secext">
<NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</NameIDFormat>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"/>
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" index="1" isDefault="true" Location="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"/>
</SPSSODescriptor>
I activated a SAML tracer and attempted the logon user journey. The AuthNRequest being sent to the Siteminder IdP based on this configuration looks like this:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"
Destination="https://test-siteminder.com/test/saml2sso"
ForceAuthn="false"
ID="_yp52mio0oj4ho2niijmnnaikgbkid9tnc5h5ear"
IsPassive="false"
IssueInstant="2020-02-17T10:19:24.279Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="pac4j-saml"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
NameQualifier="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"
>https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client</saml2:Issuer>
I can see a signature value in the Parameters section of the request, which is why I'm assuming that the AuthNRequest is signed (though my understanding of this is minimal, so that could be a wrong assumption!).
Can anyone help explain why the NameIDFormat is coming through as entity, as opposed to unspecified?
Does Apache knox support SAML1 protocols?
Thanks in advance!
You mentioned NameID format to be urn:oasis:names:tc:SAML:2.0:nameid-format:entity in your post but in the code you pasted it is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, just a copy paste error ? Looks like protocolSupportEnumeration is also referencing SAML 1 protocol. Knox uses Pac4J under the hood which does not support SAML 1, this might be the reason.
I have a question about SAML markup. I'm currently working on a project where I need to integrate a third-party application to work with windows ADFS.
I see in the sample SAML file they have sent me the makeup always starts with <saml:....>
for example:
<saml:Assertion ...>
..
</saml:Assertion>
<saml:Subject>
</saml:Subject>
<saml:Conditions
</saml:Conditions>
<saml:AuthnStatement
</saml:AuthnStatement>
...... etc
While in Windows ADFS, the SAML file that gets generated doesn't have this saml append in it's response markup.
<Assertion ...>
..
</Assertion>
<Subject>
</Subject>
<Conditions
</Conditions>
<AuthnStatement
</AuthnStatement>
i'm getting {"non_field_errors":["invalid_response"]}after ADFS login, so I'm trying to isolate what causing this to happen. cloud this be a reason for it not to work?
Check out my channel which has more than 10 videos explaining everything related to ADFS -https://www.youtube.com/channel/UCO-AQkOHCYZias9arGmQtOA
Also check this video, to know how you can verify my answer - https://www.youtube.com/watch?v=VsjhoE-M_yk
*The sample which you have received from your team, is a SAML 1.0 token, for which the saml was supposed to be used as prefix.
Below mentioned is one example. *
*But, if you request SAML 2.0 token, this prefix will not be available. *
I am spinning a big wheel now. please shed some light.
Reverse proxy is working with Apache. So, when I access https://hostname/app/default.html, it opens Tomcat app url. No issue.
The tomcat app currently redirects to https://hostname/app/login.html which has a login box.
1) Do I need to disable UserDatabase on Tomcat server.xml ?
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
2) Is this Shibboleth configuration correct ?
But, when I try configure this with OKTA- Shibboleth(3.0), it's looping OKTA SSO url.
In shibboleth2.xml
<ApplicationDefaults id="default"
entityID="https://hostname/shibboleth-sp"
REMOTE_USER="userid" >
<SSO entityID="http://www.okta.com/~~~~">
OKTA's metadata is downloaded and located with shibboleth2.xml file.
cert is also generated and placed in the same folder.
3) Is this OKTA configuration correct ?
In OKTA widget configuration menu,
- Single sign on url :https://hostname/Shibboleth.sso/SAML2/POST
- recipient url : https://hostname/Shibboleth.sso/SAML2/POST
- destination url :https://hostname/Shibboleth.sso/SAML2/POST
- audience restriction :https://hostname/shibboleth-sp <-- above SP entityID
- default relay state : ??
right now, when I click on the widget on OKTA, it's looping.
https://hostname/Shibboleth.sso/SAML2/POST
contains SAML response.
then, it redirects to OKTA SSO url. It never ends.
https:// xxx.oktapreview.com/app/xx_reverse_proxy_/xxxx/sso/saml?SAMLRequest=~~~&RelayState=~~~
This contains SAML request but it looks like this.
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://hostname/Shibboleth.sso/SAML2/POST"
Destination="https://okta sso/sso/saml"
ID="xx"
IssueInstant="2018-11-02T15:39:24Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://hostname/shibboleth-sp
</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="1"/>
Is this Issuer url correct? Why is it looping and how to fix ?
Re Q#1: You only need Tomcat users if you're going to protect an application with it, such as the Tomcat manager. Otherwise, no.
Re Q#2: You list <SSO entityID="http://www.okta.com/~~~~"> but Destination="https://okta sso/sso/saml" from the SAML. You might want to check http/https. This is a very common cause of looping. Eliminate any potential http/https inconsistency.
FWIW Issuer looks correct to me... that's what you specify in entityID="https://hostname/shibboleth-sp"
I am using ADFS 3.0 and SAML 2. I got errors like:
Exception:
'Element' is an invalid XmlNodeType. StackTrace: at
System.Xml.XmlReader.ReadEndElement() at Microsoft.IdentityServer.Protocols.Saml.SamlProtocolSerial1)izer.ReadAuthnRequest(XmlReader
reader)
Passive pipeline error
The saml request was:
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="DH7a49776ef7c040d09b2c661821bd5f76" AssertionConsumerServiceURL="https://auth-dev.ServiceProvider.com/clientOrg/SAML/Login" Destination="https://federation.example.net/adfs/ls/IdpInitiatedSignOn.aspx" IssueInstant="2017-04-20T14:49:35.6414575Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>https://auth.ServiceProvider.com/clientOrg</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" />
<samlp:forceAuthn>true</samlp:forceAuthn>
</samlp:AuthnRequest>
If the error message is too vague, how to further narrow down and trouble shoot this issue raised from the AD FS side?
Thanks.
Make sure your request is spec compliant. Use a mature SAML2 library to generate the request instead of crafting it by hand.
What is https://auth.ServiceProvider.com/clientOrg using to generate these requests?
if you remove below string, your request becomes compliant.
<samlp:forceAuthn>true</samlp:forceAuthn>
See sample at https://msdn.microsoft.com/en-us/library/ee895365.aspx to see how to use forceauthn. I also fixed destination as ad fs endpoint is /adfs/ls not /adfs/ls/idpinitiatedsignon.aspx
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ForceAuthn="true" ID="DH7a49776ef7c040d09b2c661821bd5f76" AssertionConsumerServiceURL="https://auth-dev.ServiceProvider.com/clientOrg/SAML/Login" Destination="https://federation.example.net/adfs/ls/" IssueInstant="2017-04-20T14:49:35.6414575Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>https://auth.ServiceProvider.com/clientOrg</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" />
</samlp:AuthnRequest>
Review spec at http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf for correct authnrequest.
Use validators like https://www.samltool.com/validate_xml.php to check if your request is compliant. Others might have more suggestions.