Thanks for the questions Andy, I’ve responded inline below.
One thing to note is that the Liberate service we’re launching later this year is meant to be just a starting point - with just enough features to work for those with simple requirements initially; it’ll be developed to be much more fully featured over the following months/years based off of customer feedback and its applicability and flexibility should widen considerably. It’s definitely not going to be released as-is and then not move forward.
So with that in mind, some answers:
> Liberate needs to generate the 3 main attributes ePSA, ePTID and ePe (obviously)
>
> ePSA: We currently use scripts in resolver to generate the Staff/Student/Member based on an ldap attribute.
> For example, to generate the student value we do:
>
> if ((dUNUNIaccountTypeValue=="UG")||(dUNUNIaccountTypeValue=="PG-Taught")||(dUNUNIaccountTypeValue=="PG-Research"))
> {
> if ((status=="C")||(status=="P1")||(status=="XB")||(status=="PE")||(status=="CO")||(status=="X")||(status=="CT"))
> {
> eduPersonAffiliation.getValues().add("student");
> eduPersonAffiliation.getValues().add("member");
> }
> }
Initially, we don’t support scripted attributes (for security reasons). We do support mappings (incl. regex) however, so if the above was based off a a single attribute, that would work fine, so e.g. you’d configure the ePSA attribute to connect to dUNUNIaccountTypeValue and have a set of mappings:
UG -> member
UG -> student
PG-Taught -> member
PG-Taught -> student
etc
That’s all easy to do in our web management UI.
In your particular case though, looks like you’re combining information from two separate attributes - “dUNUNIaccountTypeValue" and “status”? At the service launch, we wouldn’t be able to support that but I suspect you’re not the only one doing similar things so suspect it’ll just be a matter of time before we do.
> ePTID: Will liberate be able to retain our existing values so that users don’t lose their customisation?
Yes (unless you’ve done something weird). When we instantiate your Shib IdP, we give it a default entityId and create a salt, but these can be overridden in the management UI. So assuming that when you move to the Liberate hosted IdP we give it the same entityId as your old production IdP, the same salt, and connect it to the same source attribute from your directory, all of the generated values should be identical.
> ePe: This is the complicated one. Mostly it’s just a single value so easy enough. But what about Tallis reading lists. This is a multivalued ePe, one single line string for the students and multivalues for each staff readinglist. Currently we store both in separate string attributes. For the staff one, we have a string attribute which is semicolon separated values. The IdP then tokenises that in a resolver script and pushes values into ePe viz:
>
> if (requestContext.getPeerEntityId()==("https://login.talisaspire.com/entity"))
> {
> if ((typeof dUNUNItalisePeStaff != "undefined") && (dUNUNItalisePeStaff.getValues().size()>0))
> {
> stafftalisepe=dUNUNItalisePeStaff.getValues().get(0);
> talisentitlement=stafftalisepe.split(";");
> for (values = 0; values < talisentitlement.length; values++)
> {
> eduPersonEntitlement.getValues().add(talisentitlement[values]);
> }
> }
> if ((typeof dUNUNItalisePeStudent != "undefined") && (dUNUNItalisePeStudent.getValues().size()>0))
> {
> studenttalisepe=dUNUNItalisePeStudent.getValues().get(0);
> eduPersonEntitlement.getValues().add(studenttalisepe);
> }
> }
>
> Can liberate do this? Or what else would we have to do to be able to do this?
Not at the moment, no, that’s a fairly complex requirement. I suspect that Liberate will have to support scripted attributes in some form at some point, it just won’t at the start.
> We authenticate users who enter either cn or upn in the login box, can liberate do this? (we found many users entering upn as they do for O365 after we migrated to Azure). If only one of them, we would want to use only upn for authentication now.
Not to begin with no - out of interest, how do you actually achieve this in the Shib IdP today? I don’t think I’ve ever seen that set up, would be interested in what the config looks like.
> BTW, we aren’t authenticating or providing attributes from AD (which we keep very clean of unnecessary data) but from an ADLDS instance (actually a pair) which has userproxyfull objects (not user, so it can do proxy authentication to AD) can Liberate do this?
If it’s LDAP compliant (i.e. if it accepts bind requests and can return LDAP responses incl. the necessary attributes and values) , then it should be able to connect to it. Haven’t tested that one personally yet, but I’d be surprised if there were an issue.
> I think I heard it said in the webinar that you can also take any other LDAP attribute (givename, sn, employeeID) and punt those out in an assertion, we’re probably going to move the things that need this kind of thing somewhere else, but just in case, can you confirm this?
Yep, should be able to deal with any LDAP attribute. Users of the management UI can choose from a predefined (by us) list, but if you want new attributes adding, we can easily do that. You also configure the attribute release stuff on the same pages in the UI.
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.
