Windows ADFS SAML markup vs Standard SAML makeup - saml

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. *

Related

Keycloak adds escape characters in signature and certificate using SAML

I am trying to set up Keycloak as IdP and use it for SSO. The first re-direct (from the application login url to keycloak) works fine, but then, after entering the user credentials I get an "invalid signature" error from the application.
I have checked the SAML response (from keycloak to the application) and I can see that keycloak adds a weird escape character 
 in the certificate and signature value.
Here is part of the SAML response
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<dsig:Reference URI="#ID_fde25c3e-6958-4b49-bbe0-e4aeb200de98">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<dsig:DigestValue>p3ldrwhvbO1zoeHlhCx9TdZ01hGnw3f3IqBDIT5e1oU=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
iGNKaLxr3c9CUPpRxC3xeS0grx2FdcXWcWArlqZHdWIjQF0n9Whh5ue00HEmb+Nr5VO9jBUwRwXl
 VNEARy/4DeAsuXIxej0OYASBMjx+5qfmUIelXKLChTYjrdHyq2ZtD7BWfCrnNLtB7XiZsy8cYm0v
 ynWLlJTyxUpg+FakcxGNDnSUG6Ofslv6byQDsNY56yvqKCWbcqa1/70PD401E/Gf2XcD4paPAvHX
 B+wS25QFytqrxumRtlJiKcPS+IB8umpcHG4mKk3Qg9FxCRQk2Pk693VnEtYyQ5VXUTNFW8SfWpnQ
xDNSE6h2cevj4nT7NSQDxoNh1LRBokwjUNJWQg==
</dsig:SignatureValue>
Why does it have to truncate the signature and add the 
 escape code? Is there a way to change this?
I am sure that this is the error that is preventing the application from reading the response.
Thank you in advance

Apache Knox for SAML2 authentication keeps using NameIDFormat entity instead of what is configured

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.

Use REST calls in Hybris

I've installed Hybris 6.4 and I want to make use of its secured RESTful access to all Hybris models, that comes with the platformwebservices.
In order to have access to the REST API, i.e. requests like http://localhost:9001/ws410/rest/countries, I need to configure the OAuth 2.0
I think, I need to understand what values I need to provide in the headers:
client_id=...&client_secret=...&grant_type=...&username=...&password=...?
To test, you can simply use basic authentication with username/password (admin/***). In postman select basic authentication with username and password (Update request).
Find sample request from wiki.
Webservices are getting authenticated using the configuration in security-spring.xml.
<oauth:client client-id="client-side" resource-ids="hybris" authorized-grant-types="implicit,client_credentials"
authorities="ROLE_CLIENT" secret="secret" redirect-uri="http://localhost:9001/rest/oauth2_implicit_callback" />
<oauth:client client-id="mobile_android" resource-ids="hybris"
authorized-grant-types="authorization_code,refresh_token,password,client_credentials" authorities="ROLE_CLIENT" secret="secret"
redirect-uri="http://localhost:9001/rest/oauth2_callback" />
<oauth:client client-id="trusted_client" resource-ids="hybris"
authorized-grant-types="authorization_code,refresh_token,password,client_credentials" authorities="ROLE_TRUSTED_CLIENT"
secret="secret" />
These are the different client-id and secret codes available by default.

How to correctly configure SAML 2.0 SP

I have an Identity Provider that I wish to preform SSO against using SAML 2.0
I'm using https://github.com/KentorIT/authservices
The IdP configuration is :
Entity Id: https://xxx.yyy.com/auth
Assertion Consumer Service URL: http://zzz:1111/AuthServices/Acs
I have created a self-signed certificate and added it to the local project.
The local configuartion:
<kentor.authServices entityId="https://xxx.yyy.com/Files/Metadata/IdP/Saml"
returnUrl="http://localhost:8585/">
<identityProviders>
<add entityId="https://xxx.yyy.com/"
signOnUrl="https://xxx.yyy.com/Saml/Login.aspx"
allowUnsolicitedAuthnResponse="true" binding="HttpRedirect">
<signingCertificate fileName="~/App_Data/SelfSignedCertificate-2016-01-10-22-37.cer" />
</add>
</identityProviders>
<federations>
<add metadataLocation="http://localhost:52071/Federation" allowUnsolicitedAuthnResponse="true" />
</federations>
</kentor.authServices>
I will appreciate any kind of help as i'm stuck with this.
Thanks
Gilad
The first entityId, in the kentor.authServices root element should be the identifier you use for your site. Typically http://zzz:1111/AuthServices, which is the ACS url minus the last part.
The signingCertificate within the identityProviders/add element should not be your own certificate, but the certificate that the Idp uses to sign messages.
The federations element should be completely removed. It points to the local development environment, that it looks like you've copied the config from.

Jenkins and SAML plugin issues using SSO Auth

Jenkins v 1.597
SAML plugin v 0.3
We are using an internal PingFederated server and I have entered the xml metedata contents into the Security configuration of Jenkins.
I have tried on two servers, one set up HTTPS (SSL) and one just HTTP.
We get errors when trying to login using SSO that pertain to the https://servername/securityRealm/finishLogin redirect and the same for non-SSL server.
We are stumped on what to check here, the PingFederated administrator has it set for the postback to the securityRealm/finishLogin URL, which is what is in the code for the plugin, we just are not sure how to proceed.
The contents of the xml metadata:
<md:EntityDescriptor ID="MNkL_uYrUsdEca2oWqH6gdgG4t3" cacheDuration="PT1440M" entityID="ACIWW:Saml2:POC" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data> <ds:X509Certificate>CERTIFICATECODE HERE</ds:X509Certificate></ds:X509Data> </ds:KeyInfo></md:KeyDescriptor><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://SSOSERVERNAME/idp/SSO.saml2"/></md:IDPSSODescriptor><md:ContactPerson contactType="administrative"><md:Company>COMPANYNAME</md:Company></md:ContactPerson></md:EntityDescriptor>
Any help or suggestions would be greatly appreciated.
John