Hi Misagh, As I started to propose today on CAS-1296 ( https://github.com/Jasig/cas/pull/361), I think we need a stronger concept on attributes release. So far, we have : the *ignoreAttributes* and *allowedAttributes* properties and maybe an *attribute filter* (which applies after).
What about the creation of an attribute "releaser" defined at the service level, whose role would be to take all the attributes of the principal and release them for the service ? We would have a *ReturnAllAttributesReleaser* (for *ignoreAttributes*), a *ReturnAllowedAttributesReleaser* (for *allowedAttributes*) and a *ReturnedMappedAttributesReleaser* in your case. Does it make sense ? It's a bigger change I admit, but I think it's more flexible. Best regards, Jérôme 2013/11/30 Misagh Moayyed <mmoay...@unicon.net> > Team, > I'd like to propose an API change; for registered services to be able to > define their own attribute mapping that is essentially, renaming a given > attribute. The use case I have in mind is detailed as following: > > Principal attributes are: > A = V1 > B = V2 > > Allowed attributes for the service S are: > A > B > > While other services are happy receiving A and B (as they are allowed), > service S would want to virtually rename A and B to be called X and Z. > > So it gets to define its own mapping: > A => Z > B => X > > ...which is to say that attribute A upon release time, should be named as > Z and B as X for service S only. (very similar to the idea of releasing > usernames per service). > > So that S receives: > Z = V1 > X = V2 > > ...while every other service can rely on the default mappings to still > receive A and B as allowed. > > Use case: > Certain cloud-services that support CAS demand specific attribute names to > be released. These attributes may already be in use by other applications. > person-directory heroics are either not possible or pretty ugly in order to > accommodate this case. > > So the API change I have in mind includes the following: > > 1. Define a property on a registered service, as Map, to return custom > mappings > 2. On service validation, work on the merged result of allowed and custom > mappings, and proceed based on that. > > Backwards compatible, as custom mappings may be void. > > Sound reasonable? > > Misagh > > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
