Uncertainty about scopes in metadata and it's relation to scoped attributes.

[Mathis, Bradley]

Thanks David,  I had thought about that... though I wasn't sure how our
vendor would/could handle .. it is something to consider. ... the IDs are
unique ..so it's a definite maybe.


Brad Mathis
IT Principal Systems Analyst
Infrastructure Services - Applications
Pima Community College
520.206.4826
bmathis at pima.edu









On Wed, Jul 3, 2019 at 12:02 PM IAM David Bantz <dabantz at alaska.edu> wrote:

> To keep your ePPNs scoped @pima.edu :
>
> Assuming staff & students have unique non-colliding IDs in a single
> name-space (which seems likely if both groups authenticate by providing
> those IDs):
> Assign ePPN of student1 at pima.edu [instead of the email address] in
> attribute-resolver.
> That does presume the vendor does not rely on the scoped principal name
> doubling as a valid email address (alas some do).
>
> David Bantz
> UA OIT IAM
>
>
> On Wed, Jul 3, 2019 at 9:45 AM Mathis, Bradley <bmathis at pima.edu> wrote:
>
>> First off,  thank you for your time in reading this for any patience you
>> can have with my lack of understanding how metadata works or is used.
>>
>> We have a helpdesk/ticket tracking system that we are using.  We are the
>> idp and they are the SP and they/we are using InCommon in this case for our
>> metadata repository.
>>
>> We are sending the eduPersonPrincipalName along with a few other basic
>> attributes at login.... though I'm pretty sure the eduPersonPrincipalName
>> is what is being
>> used to actually login/authorize access.
>>
>> Currently all our College staff are able to login and use the system.
>> For example my eduPersonPrincipalName value is e.g.  bmathis at pima.edu
>> this works fine.
>>
>> We now have some who want to add students to the system.  When they
>> attempt login they are denied access (actually it looks like it goes into a
>> loop).  The student eduPersonPrincipalName value is using a subdomain like
>> this student1 at mail.pima.edu.
>>
>> We have asked the vendor to allow users that have eduPersonPrincipalName
>> value of username at mail.pima.edu to be valid users of the system.
>>
>> Their response was that we would need to change our metadata with
>> inCommon to allow the new scope... I assume they mean add mail.pima.edu
>> to the scope ...
>> I do see we have a scope in our metadata for pima.edu .... which is
>> correct.   Due to my ignorance I'm not certain if what they are asking is
>> valid .... I have read some of the
>> Incommon documentation about it ... at
>> https://spaces.at.internet2.edu/display/InCFederation/Scope+in+Metadata
>>  but I'm still processing it.  It appears I can add another scope but it
>> will most certain generate manaul vetting if I do.
>>
>> I guess I just want to make sure..... is this really needed to resolve
>> our issue?
>>
>> We are sending them the correct value for the user in the
>> eduPersonPrincipalName I'm not understanding why our metadata needs the
>> scope added... why can't they userthe
>> eduPersonPrincipalName we send them.
>>
>> I figure they really know what they are talking about or .. they might be
>> as uneducated about it as I am :-)
>>
>> Thanks for any feedback you have.
>>
>>
>>
>> Brad Mathis
>> IT Principal Systems Analyst
>> Infrastructure Services - Applications
>> Pima Community College
>> 520.206.4826
>> bmathis at pima.edu
>>
>>
>>
>>
>>
>>
>>
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190703/fc1acef3/attachment.html>