> Yes, exactly. I can see a real use case too, not only for testing. Lets
> imagine University of Murcia (UMU) is willing to provide their students
> with access to a Linux server, not matter whether they are local or
> foreign (e.g. erasmus programme). Instead of creating a specific account
> for every user, UMU just want them to log in a common account called
> "student". Therefore, any student that wants to access this terminal
> service, just need to execute "ssh [log in to unmask]".

Sure, but in that case you probably don't just create the attribute for no reason, it will depend on *something* in the input. Otherwise you're equating authn and authz and that's a bad idea.

> Now, ssh.um.es does not care about the actual identity of the user. It
> just need to know they are valid users within the federation (just like
> eduroam does).

If eduroam does that, than they are allowing anybody in the world to get in. Something has to be checked, or there's not much point in bothering with authentication. There's no such thing as "valid user in federation" unless the federation is very constrained, or the policy is very meaningless.

> The mapping to the local username will be always "X" ->
> "student", no matter what the SAML assertion says (if any).

Bad idea, per the above.

> Thank you. I will look at them. Are they included into the moonshot's
> git server?

Probably, but I would think you wouldn't need that copy of the SP at all, just use official sources at this point.

-- Scott