search

pingidentity / scim2

The UnboundID SCIM 2.0 SDK for Java
180 stars 74 forks source link

com.unboundid.scim2.common.types.Adress is missing "value" and "display" attributes #108

Open wwebers opened 5 years ago

wwebers commented 5 years ago

Adress is a multi-valued type according to RFC-7643. However, it's missing the both attributes "value" and "display".

That leads to problems when using the client library with SCIM2 conformant servers.

kqarryzada commented 1 year ago

Unless I'm mistaken, I don't see either of those fields for addresses in RFC 7643 section 4.1.2:

addresses A physical mailing address for this user. Canonical type values of "work", "home", and "other". This attribute is a complex type with the following sub-attributes. All sub-attributes are OPTIONAL.   formatted
The full mailing address, formatted for display or use with a mailing label. This attribute MAY contain newlines.   streetAddress
The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines.   locality
The city or locality component.   region The state or region component.   postalCode The zip code or postal code component.   country The country name component. When specified, the value MUST be in ISO 3166-1 "alpha-2" code format [ISO3166]; e.g., the United States and Sweden are "US" and "SE", respectively.

I'm going to close this, but let me know if you find any indication that these two attributes are expected.

wwebers commented 1 year ago

@kqarryzada I propose to reopen this issue as your reference to RFC 7643 section 4.1.2 is just one part. As stated there address is a multi-valued and complex type. The attributes for multi-valued types are defined in RFC 7643 section 2.4. All other classes for multi-valued in this package respect the standard, but addresses. Problem is that the absence of display and value leads to problems during serialization/deserialization at servers expecting such attributes according section 2.4 of the RFC.

kqarryzada commented 1 year ago

Certainly. I haven't gotten a chance to look into this much further, but wanted to re-open it right away. I'll let you know if I have further questions.

kqarryzada commented 1 year ago

@wwebers, this is tricky. I've taken a look at section 2.4, and I notice that it says:

If not otherwise defined, the default set of sub-attributes for a multi-valued attribute is as follows: type primary display value $ref

In section 4.1.2, addresses is the only attribute that lists a set of its own sub-attributes. It also says:

This attribute is a complex type with the following sub-attributes.

So it doesn't imply that the listed sub-attributes are in addition to the default set of attributes. To me, these two sections suggest that the default set of attributes do not apply to addresses. However, the section does mention that type is a valid field, though, which makes this confusing. The SCIM SDK does support this explicitly mentioned field, at least.

What SCIM servers/services have you seen that accept addresses.value and addresses.display as valid attributes?

wwebers commented 9 months ago

Sorry for the late answer. Anyway, when I started this issue we tried out PingIdentity as well as an own solution realized on the IdentityServer framwork, which worked fine for another SCIM framework. Obviously, the SCIM specification leaves some room for interpretation, which is unfortunate. IMHO, such type of specifications should not leave such a head room.