Is there a standard format of SAML 2.0 encrypted assertion - saml

I am implementing an SP initiated web browser SAML SSO profile in JBOSS.
My application is the SP.
After login, I expect the IDP to send me an encrypted assertion of the following format:
<samlp:Response...>
<ds:Signature>...
<ds:KeyInfo>....</ds:KeyInfo>
</ds:Signature>
<samlp:Status>...</samlp:Status>
<saml:EncryptedAssertion>...</saml:EncryptedAssertion>
</samlp:Response>
It works fine for some of the IDPs, but now I have an IDP which sends me:
<saml2p:Response...>
<saml2p:Status>...</saml2p:Status>
<saml2:EncryptedAssertion>...
<ds:KeyInfo>...</ds:KeyInfo>
</saml2:EncryptedAssertion>
</saml2p:Response>
And the authentication fails since the signature is missing.
My question is: Is there a standard format of SAML 2.0 encrypted assertion which I can tell the IDP admin to use? Or must I support both ways?
Thanks

According to the XMLenc standard that is used in SAML2. KeyInfo can be used. But inside the encrypted data not inside the encrypted assertion.
Signature on response is optional as reflected by 5.2 in the SAML spec
So If this is the case you can't make them change for not following the standard.

Related

How To Configure openam SAML2 service provider to use NameID Format unspecified

currently, we use openAM version 13.0.0 as a service provider for SAML2 SSO.
How To Configure openAM SAML2 service provider to use NameID Format unspecified?
Edit :
I faced the following issue :
ERROR: spAssertionConsumer.jsp: SSO failed. com.sun.identity.saml2.common.SAML2Exception: No local user being mapped. at com.sun.identity.saml2.profile.SPACSUtils.processResponse(SPACSUtils.java:1225)
Given you use spSSOInit.jsp to trigger SP-initiated SSO flow, you can specify the NameID format to be sent (NameIDPolicy element in SAML AuthNRequest) by using request parameter NameIDFormat. If it's supported by the SP and IdP, it will be used. If you do not specify this request parameter, OpenAM tries to find the first NameID format that is supported by both entities. If the IDP does not specify anything, the first NameID format of the hosted SP is used.

saml okta redirect idp fails

I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)
The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404.
Is there a way to figure out what is causing the issue?
Install SAML tracer browser extensions and try it again to confirm the SAML Response is being decoded correctly.
To address your question "Is there a way to figure out what is causing the issue?", I have repeated your SAML 2.0 authentication steps suggested by your post.
The following responses and answer will help you to "figure out what is causing the issue".
(1) Quote your post "I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)"
Response:
(I) I have created a SAML 2.0 SP App on okta and have finished all the configurations as you did.
(II) I then attempt to do an authorization from my SAML SP application, by doing a redirect to the okta idp as you did.
(III) Submit the username/password of local Okta user account (e.g., john.doe#example.com) to proceed with SAML authentication.
(2) Quote your post "The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404."
Response:
(I) In my experiment, the redirect returns the following error message instead of a 404 error.
Sorry, you can't access SAML 2.0 SP demo because you are not assigned this app in Okta.
If you're wondering why this is happening, please contact your administrator.
If it's any consolation, we can take you to your Okta home page.
(II) Then "I go to my admin okta console" as suggested by your post,
navigate to Reports > System Log, I saw the log below.
Event Info Targets
User attempted unauthorized access to app SAML 2.0 SP demo (AppInstance)
FAILURE :
(3) Quote your question "Is there a way to figure out what is causing the issue?"
Answer:
I summarize the four (4) potential root causes of your SAML authentication failure. The top #1 potential root cause is that you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (see the detailed description below).
(I) Potential Issue #1:
The root cause of my issue is that my local okta user account was NOT assigned to access this SAML 2.0 App.
Resolution:
(a) Navigate to Applications > SAML 2.0 App, then click Assign > Assign to People,
(b) On the pop-up dialog box, select the local Okta user accounts (e.g., John Doe (john.doe#example.com)), click Assign, click Save and Go Back, then click Done.
(c) Repeated the above SAML 2.0 authentication steps again, I was redirected back and logged in to SAML 2.0 App successfully.
(II) Potential Issue #2:
Three (3) potential root causes of this issue are that
(a) you did NOT fill in all the correct SAML SP information of your SAML 2.0 SP app on okta.
(b) or you did NOT upload the okta IdP metadata file into your SAML 2.0 SP app server
(c) or you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (this is the highest probability for bringing your 404 failure, because unlike most of SAML IdPs which create only one IdP metadata file for all SAML SP apps, okta create different IdP metadata files for different SAML SP apps).
Resolution:
Regarding to root cause (II.a): You need to ensure that the following SAML SP information should be the exactly the same as the SAML SP metadata of your SAML 2.0 SP app when you create new SAML 2.0 app.
Single sign on URL should come from your SAML SP metadata, e.g.,
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-saml-sp-app-URL/SAML2/POST" index="1"/>
Audience URI (SP Entity ID) should also come from your SAML SP metadata, e.g.,
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_random-string" entityID="https://your-saml-sp-app-URL/SAML2/Metadata">)
The sample SAML Settings of SAML 2.0 SP app on okta
Navigate to Applications > your SAML 2.0 App > general > SAML Settings
Single Sign On URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Recipient URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Destination URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Audience Restriction https://your-saml-sp-app-URL/SAML2/Metadata (i.e., your SAML SP entity ID)
Default Relay State
Name ID Format Unspecified
Response Signed
Assertion Signature Signed
Signature Algorithm RSA_SHA256
Digest Algorithm SHA256
Assertion Encryption Unencrypted
SAML Single Logout Disabled
authnContextClassRef PasswordProtectedTransport
Honor Force Authentication Yes
SAML Issuer ID http://www.okta.com/${org.externalKey}
Regarding to root causes (II.b) and (II.c): You need to upload the correct okta IdP metadata into your SAML 2.0 SP app server.
Note that okta creates different okta IdP metadata files for your different SAML 2.0 SP apps.
Navigate to Applications > your SAML 2.0 App > Sign On
Identity Provider metadata is available if this application supports dynamic configuration.
Click Identity Provider metadata to download the okta IdP metadata for your SAML 2.0 SP app.
Log in to your SAML 2.0 SP app, upload the okta IdP metadata into your SAML 2.0 SP app, and then complete the configuration to store the okta IdP information on your SAML 2.0 SP app server.

OneLogin + SAML + SCIM

I'm integrating a service with OneLogin. In particular, need to implement SAML-P login AND SCIM v2 endpoint in a multi-tiered .NET application, which is using Windows Identity Foundation behind the scenes.
Both SCIM v2 and SAML-P work fine independently, however I'm having issues combining these two in the same SP record OneLogin-side, because of signing options:
It is possible to get OneLogin to sign just SAML assertion in a SAML response. This is what WIF wants to see, and this is what "SAML Test Connector (IdP)" template of OneLogin does.
"SCIM Provisioner with SAML (SCIM v2)" template however signs the whole SAML response, and not just the assertion, and WIF does not like that, complaining about unsigned SAML assertion.
Neither template has a visible option to configure what is signed, that would be similar to what Azure AD SAML configuration has (e.g. https://i.stack.imgur.com/f9kFf.png ).
Is there a way to change SCIM template to sign just the assertion (or response + assertion), similar to what "SAML Test Connector (IdP)" does?

SAML Claims not returned by WSO2 IS 5.1.0

I am using WSO2 5.1 – STS service. With the stsclient (java program) I am making a SAML token request. However, I am not getting the claims details as part of the SAML token response from IS.
The same request is returning the claims when a request is sent to WSO2 IS 5.0.
For SSO requirement Looks like I have to set “Attribute Consuming Service Index”. But not sure where to set this attribute in the SAML request while using the stsclient java program.
This resembles this question but not related to STS.
In your Service Provider's SAML configuration, you have to make sure following two checkboxes are checked.
Enable Attribute Profile
Include Attributes in the Response Always
Then, inside the Claim Configuration section of the Service Provider, you have to add the particular user claims that you wish to receive in SAML response as the Requested Claims.
Then you should be able to receive the user claims in SAML response, provided that user's profile already contains values for these claims.
Refer [1] for more details.
[1] http://tharindue.blogspot.com/2016/08/retrieving-user-claims-in-saml-response.html

SLO with wso2is, idp not including Issuer in LogoutRequests

I am using wso2is as idp and 2 applications as sp in this setup. one of the applications uses java, spring-security-saml-extension, the other one php and simplesamlphp. SSO is working good, but i cannot get SLO working.
what i do is:
login in both sp-s
do a logout in 1st sp
watch wso2 log and see that wso2is sent a logoutrequest to the 2nd sp
2nd sp fails to read logoutrequest
simplesamlphp error message:
SimpleSAML_Error_BadRequest: BADREQUEST('%REASON%' => 'Received message on logout endpoint without issuer.')
saml2 LogoutRequest issued by the idp:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutRequest ID="ljknoccfdhjcgelcpmbicffooeokboficpggcmpi" IssueInstant="2014-04-08T06:45:19.944Z" NotOnOrAfter="2014-04-08T06:50:19.944Z" Reason="urn:oasis:names:tc:SAML:2.0:logout:user" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">EXAMPLE.AT/test01#domain.com</saml2:NameID>
<saml2p:SessionIndex>5f14fc6e-1c31-42e1-b7c2-e1501bf400a8</saml2p:SessionIndex
</saml2p:LogoutRequest>
The saml2 SLO-Profile specification below clearly states in chapter 4.4.4 on line 1294:
The <Issuer> element MUST be present and MUST contain the unique
identifier of the requesting entity
as I understand this the wso2is acting as the Idp should be the Issuer here, but it fails to include its id in the message.
Any hint on what i am doing wrong? i cannot imagine that this is a wso2is bug!
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
As you found in the specification, the Issuer element is mandatory. SP uses it to identify the sender. Without it SP would have to start guessing who sent the message, as it might be connected to many IDPs at the same time. The issue should be reported as a bug to wso.
This is fixed in the upcoming Identity Server 5.1 release.
https://wso2.org/jira/browse/IDENTITY-2714
I am currently using 5.0.0 and ended up patching a number of things such as this so I could have the functionality I needed. It wasn't too bad to do once you get oriented. You'd need to patch the 'org.wso2.carbon.identity.sso.saml' component in the 'identity' module of carbon platform's 4.2.0 chunk11.