| Time |
S |
Nick |
Message |
| 02:35 |
|
pdurbin |
hmm. the 'the "Where Are You From" (WAYF) service' -- http://www.switch.ch/aai/support/tools/wayf.html |
| 02:37 |
|
pdurbin |
if harvard has this i haven't heard of it |
| 04:10 |
|
pdurbin |
simmel: i haven't read through that page yet but the thing i keep seeing about shibboleth... in the apache examples anyway... is that they're protecting certain directories. it's almost like the use case is for an institution that has licensed some software and only wants their students (for example) to be able to download it. i'll keep reading but that's my first impression of a main use case for shibboleth... that it can be used to protect certain di |
| 04:11 |
|
pdurbin |
whoops cut off |
| 04:11 |
|
pdurbin |
i'll keep reading but that's my first impression of a main use case for shibboleth... that it can be used to protect certain directories. like you can do with apache basic auth |
| 04:12 |
|
pdurbin |
"I have made this letter longer than usual, only because I have not had time to make it shorter." -- http://www.twainquotes.com/Letters.html |
| 11:48 |
|
simmel |
pdurbin: You can do anything that is related to authentication and authorization. |
| 11:49 |
|
simmel |
pdurbin: From the IDP your SP will receive attributes which contains information about the user (think LDAP attributes) e.g. affiliation (student, employee) groups they are members of, (email|postal) address etc. BUT the IDP must release the attributes you need/want to your SP. |
| 12:27 |
|
pdurbin |
simmel: right... like eduPersonAffiliation |
| 12:28 |
|
pdurbin |
i wonder if the only attribute i would need from the IDP is the username |
| 12:29 |
|
pdurbin |
and then in my app i could continue to say user1 is an admin, user2 is not, etc... I imagine i could still do that |
| 12:30 |
|
pdurbin |
this would be like using shibboleth only to tell me if usernames are valid and if users have provided the right password |
| 12:30 |
|
pdurbin |
and the rest of the logic is handled in the app, based on the username provided |
| 15:32 |
|
pdurbin |
simmel: i'm sorry but i haven't had a chance to read your suggestion at http://irclog.iq.harvard.edu/dvn/2013-01-09#i_321 yet. i have a talk to give on monday and i'm actively writing the content for http://dvn.github.com/dvn-sourceforge2github/ |
| 16:08 |
|
simmel |
pdurbin: Yes you could. If you trust the IDPs enough you can let them handle who's admin and not via a attribute (ePA e.g.) |
| 16:11 |
|
pdurbin |
simmel: right, ok. i guess what i'm thinking is... what if the person installing our app has a hard time getting changes through the IDP they want to auth against? this might be more common in large institutions, where a different group runs the IDP. what if the IDP guys don't want to or are slow to add custom attributes, i mean, if that makes sense |
| 16:11 |
|
* pdurbin |
checks to make sure my text wasn't truncated again. phew! |
| 16:49 |
|
simmel |
If you have collaboration problems then you have it no matter what technology you are using. Don't solve it using identity silos = ) |
| 16:50 |
|
pdurbin |
what collaboration problems? ;) |
| 17:00 |
|
pdurbin |
uh oh! trouble with my https://github.com/pdurbin/dvn-vagrant behind a proxy? reported at https://groups.google.com/d/msg/dataverse-community/wRxRSGE8VpQ/UeGThjqHBQYJ and i'm bringing it up in #vagrant: http://irclogger.com/.vagrant/2013-01-10#1357836920 |
| 17:23 |
|
* pdurbin |
leaves a comment at https://github.com/mitchellh/vagrant/issues/498#issuecomment-12107950 |
