cancel
Showing results for 
Search instead for 
Did you mean: 

SAML Attributes are returned as Array instead of Variables in Cloud Foundry

matteoprinetti
Participant
0 Kudos

Hi, we are having this issue.

We have a Cloud Foundry Subaccount connected to our Entreprise ADFS. The problem ist that the attributes coming from SAML are converted into array instead of variable.

Example:
SAML as seen in Chrome SAML Debugger:

   <Attribute Name="login_name">
    <AttributeValue>username</AttributeValue>
   </Attribute>

What the call to userapi/attributes returns:

"login_name": [
    "username"
 ]

The same call on Neo services/userapi/attributes - connected to same ADFS, all settings the same:

login_name: "username"

The effect on this is that the cloud connector (and also our apps) dont find the the attribute "login_name" and cannot create a proper x509 certificate (it get generated with CN=emailofusername@email.com instead of CN=username).


We suspect that the BTP Module which reads the SAML Request, for some reason, returns single Attributes as a Array with one Value instead of a single Value.

Blume
Explorer
0 Kudos

Hi Matteo,
Thanks for all the details shared!

  1. What issue is this causing? Having the exact symptom / error message helps with proposing a solution (if possible, attach a screenshot here)
  2. What kind of scenario are you trying to setup? Since you are mentioning the X.509 Certificate from Cloud Connector, I believe this is related to a Principal Propagation scenario
  3. Are you referring to any documentation when trying to setup this scenario?

Wishing you all the best,
Vini
SAP Support

Accepted Solutions (0)

Answers (1)

Answers (1)

Blume
Explorer
0 Kudos

Hi Matteo,

Complementing my comment with a possible solution:
If you are indeed trying to setup Principal Propagation, I suggest you to carefully review and setup your scenario as described in How to Guide – Principal Propagation in an HTTPS Scenario.

If this does not help, proceed with answering the questions I asked in the comments.

All the best,
Vini
SAP Support

matteoprinetti
Participant
0 Kudos

Hi Vinicius, thank you for your reply.

We noticed the issue while we are transitioning from Neo to CF. It could be a cloud connector issue, this is how we are able to replicate it.

a) setup a cf subaccount trusting a corporate AD - which is configured to deliver the attribute "login_name" (which is of course a AD attribute)

b) setup the cloud connector as usual - mapping the login_name to the CN attribute

c) on trying to access the backend, we get 401 errors. Looking at SMICM on the backend we see the x509 certi having CN=email_address_from_ad instead of CN=login_name

d) looking on the BTP side (with the userapi) we see the claim in array format instead of the single value.

e) looking with the SAML Chrome Debugger we see the claim coming correctly as single Attribute

So (I suspect) the btp module which reads the SAML answer and translates the answer in user attributes (the ones read by the userapi) for some reason translates it into array. The cloud connector expect single values and not array to be mapped so it does not find the attribute and defaults to the email address.

The same exact scenario above but with a neo subaccounts works perfectly (this is our production). So maybe someone has to look in the btp modules for neo and cf and see if there is any difference there (I believe those are java classes but are not published).

BTW is it is not wrong to treat attributes as arrays, as per SAML definition there can be more keys to a single attribute. What I believe the error is, the CF module should deliver the attribute as a single value if there is only one key. The way it works now (at least in our case) only the "standard" SAML Attributes firstname,lastname,email,name are delivered as single values. All the others are treated as array even if they have one single key.

So either the module needs to looked at, or on the cloud connector the mapping should consider that the value can be an array and in this case take the first value (or the mapping can have something like mail=login_name[1] to indicate it wants the 2nd value.