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
----- Original Message -----
From: "Jérôme LELEU" <lel...@gmail.com>
To: cas-dev@lists.jasig.org
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 < 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: mmoay...@unicon.net
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
