Hi, This change makes sense to me for a 4.x. And yes, "ignoreAttributes" is pretty confusing. Best regards, Jérôme
2013/12/3 Misagh Moayyed <[email protected]> > Just a side note; that I have through observation found the term > "ignoreAttributes" to be confusing for adopters. It somehow gives the > impression that attributes are entirely ignored and nothing is actually > sent, while the opposite is in fact true. Exacting the terminology of > filtering policy would help to remove confusion there too. > > Misagh > > ------------------------------ > *From: *"Misagh Moayyed" <[email protected]> > *To: *[email protected] > *Sent: *Tuesday, December 3, 2013 2:06:58 AM > *Subject: *Re: [cas-dev] attribute mapping per registered service? > > Right. It does make sense to me that perhaps we should combine the > concepts of releasing and filtering attributes into one. Filtering is > simply just another optional step in the release process that is not > distinct by itself. So I gather we can have something like this based on > your description: > > - A policy interface and a way to plugin in the filter. Roughly, something > like this: > > interface AttributeFilteringPolicy { > setAttributeFilter(AttributeFilter f); > Map getAttributes(); > } > > Then, we'd have 3 policies as you note below: > - Return all, returned allowed, or returned mapped attributes > - Each policy would return attributes, having optionally applied the > attribute filter. > > - We'd remove "ignoreAttributes" and "allowedAttributes" from the service > and allow for an injection point for the configured policy. Default would > be what we have now, that is returning only allowed attributes with no > filters. > > - To obtain the final result, one would invoke something like: > registeredService.getAttributeFilteringPolicy().getAttributes() > > Sound fair? > > Misagh > > > ------------------------------ > *From: *"Jérôme LELEU" <[email protected]> > *To: *[email protected] > *Sent: *Monday, December 2, 2013 7:54:13 AM > *Subject: *Re: [cas-dev] attribute mapping per registered service? > > 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 <[email protected]> > >> 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 [email protected] as: [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
