Shibboleth Developers

["Alistair Young" <>]

Hotmail would never come into it. The domain suffix is the domain of the
user's institution. Although it looks like an email address, it may not
be.
The iName looks bizarre. I'd love to see students getting to grips with it :)
Domain suffix:


iName
@org.ac.uk*user

I think I'd prefer the first one to be honest. As in the case of iName,
it's directly resolvable to their IdP location. What I was proposing for
the VLE use case is a known end point at that domain, or it could be
overrided in metadata to point to a different end point SSO.

In the VLE, we have to avoid namespace clashes. There may already be a
joebloggs user account locally. All VLEs have local user databases AFAIK.
So 

 would mark the user as external and coming in via
shib.
If they didn't, they'd continually get "invalid password" errors from the
VLE as it thinks they're local.

No domain suffix? Then the VLE should treat them as local and
authenticate/authorise out of it's normal database.

As for the IdP sending an agent to gather assessment info for a suffixed
ID, I think it would authenticate as itself. Being, in effect, a proxy for
the institutional dept/faculty/lecturer that wants the info. Whether the
lecturer etc. is allowed to have a proxy gather assessment info would be
authorised on the IdP side, so the SP need not bother with complicated
policy. The IdP side should decide whether the agent can be sent.

The only policy on the SP would be 

 can't gather info for


Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

>> For instance, an IdP could initiate an agent to gather assessment info
>> for
>> students on it's behalf. In this case, there's no UI. Rather, the agent
>> would have an X509 that it presents.
>
> I don't quite follow the use case, I guess. What kind of gathering
> operation? Is the IdP authenticating as itself or impersonating users?
> With
> what interface? Doesn't sound like a browser use case, therefore it's not
> really addressed by anything we've done so far anyway.
>
>> I'm not sure what you mean though, where the "local" access can be
>> combined with shibboleth type access in the UI of the application.
>> Is this different from federate authentication within the UI?
>
> The application UI itself treats all users the same. If you need a "local"
> user database (not always even a good idea), then that just becomes one of
> the choices. I don't think I have to enter an ID (and screw it up) to
> indicate how I need to login. It might just be the "use this if you don't
> recognize anything else" choice.
>
> It just seems like duplicate entry to me and doesn't strike me as intutive
> for users unless you try and assume that their email address will match,
> which will get you some hotmail.com and gmail.com entries, etc.
>
> I'm not saying it's crazy or anything, just that I've been skeptical that
> it
> helps greatly.
>
> I think the big problem is the lack of any well-understood-by-users
> "label"
> to apply to this thing you want them to enter. I was talking to the XNS
> guys
> that we met in Austin last fall about this idea that people could enter
> this
> personal i-name thing and it would resolve as an XRI into their IdP.
> Interesting idea, except that nobody knows what the heck an i-name is and
> few have them.
>
> -- Scott
>
>