On 5 Jul 2017, at 10:17, Andy Swiffin (Staff) <[log in to unmask]> wrote:
>
> Hi,
>
> I hadn't seen a reply to this, there are some important questions that need answering before we could consider Liberate as a possible service.
> Particularly, how will it generate ePe values which are multivalued. Would a site need to create a multivalued string attribute? Can you consume that?
Sorry - my bad, hadn’t replied yet. One of those weeks.
Answers below.
> ePSA : we could get around by turning it into a group or just combining the values with FIM so not an issue.
Cool.
> ePe: So, how do you propose supplying Liberate for anyone running Tallis Aspire? We could combine all of the values, using FIM, into one multivalued string attribute, can you consume that and release it as ePe? This would be a complete show stopper for anyone using Tallis.
I’d never seen how Talis Aspire uses ePE before, that’s interesting.
At the moment, the attribute handling is relatively simple - as I said, you hook it up to an attribute in LDAP, and can do exact match/regex mapping from LDAP values (incl DN and group membership) to mapped values. This should generally work for multivalued attributes. So if the ePE values were stored in an attribute somewhere in the directory, these can be released.
Are the reading lists consistent across say, all staff, and all students (or a manageable number of groups of students)? Or are they different per student? I’m thinking if you set up groups and mapped from group membership to multiple values (so e.g. if in staff group they get entitlement A & B, if in undergrad student group they get entitlement C D & E, etc etc), that might work.
Beyond that, as I said, Liberate’s first version is intentionally fairly simple, but we’ll have a fairly robust development of the service based on requirements that percolate up, so if something isn’t supported from the get-go it certainly doesn’t mean it won’t ever be - far from it.
One thing we’re considering is limited support for scripted attributes - as in, Liberate customers can’t directly edit the scripts in scripted attributes (security reasons), but can request that we configure them on their behalf. If we do that, then the sky’s the limit really.
> Ambidextrousness concerning cn or upn to login? Very very easy.
> In resolver:
> <![CDATA[
> (|(userPrincipalName=$requestContext.principalName) (cn=$requestContext.principalName))
> ]]>
>
> In login.config: userFilter="(|(userprincipalname={0})(cn={0}))”
Ah awesome, of course. Not supported today, but wouldn’t be hard to add support for that.
> Not an issue for us as we'd just mandate upn for everything and ditch cn, it fits in with O365 and so users now expect it. You can just use upn?
You can choose any attribute in the directory to try the bind against.
Rhys.
--
Dr Rhys Smith
Chief Technical Architect, Trust & Identity
Jisc
T: +44 (0) 1235 822145
M: +44 (0) 7968 087821
Skype: rhys-smith
GPG: 0x4638C985
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
|