> Ola Alejandro,
>
> You can amend your FreeRADIUS configuration post-auth section with the following change if you want:
>
> if ( ("%{request:X-Ascend-FR-DCE-N393}") || ("%{request:GSS-Acceptor-Service-Name}") ) {
> 	update reply {
> 		SAML-AAA-Assertion = '<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2011-03-19T08:30:00Z" ID="foo" Version="2.0">'
> 		SAML-AAA-Assertion += '<saml:Issuer>urn:mace:incommon:osu.edu</saml:Issuer>'
> 		SAML-AAA-Assertion += '<saml:AttributeStatement>'
> 		SAML-AAA-Assertion += '<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">'
> 		SAML-AAA-Assertion += "<saml:AttributeValue>[log in to unmask]</saml:AttributeValue>"
> 		SAML-AAA-Assertion += '</saml:Attribute>'
> 		SAML-AAA-Assertion += '<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7">'
> 		SAML-AAA-Assertion += "<saml:AttributeValue>guest</saml:AttributeValue>"
> 		SAML-AAA-Assertion += '</saml:Attribute>'
> 		SAML-AAA-Assertion += '</saml:AttributeStatement>'
> 		SAML-AAA-Assertion += '</saml:Assertion>'
> 	}
> }
>
> The difference here is that ONLY if the request to the FreeRADIUS server contains the attribute "X-Ascend-FR-DCE-N393" or "GSS-Acceptor-Service-Name" (both map to the same ID, although the latter is correct, and the Moonshot mechanism always sends it), will the Access-Accept reply contain the SAML assertion. So if a normal eduroam request comes in, this portion is not sent back. As far as I know, both attributes should be filtered out by the attr_filter.post-proxy anyway (they are not on the list of 'approved' eduroam attributes).
Hi Stefan,

thanks for the answer. Actually, attribute filtering was my motivation. 
In the tests I've been doing so far, SAML-AAA-Assertion was being 
filtered. That's why I was looking for a non-SAML alternative, based 
just in RADIUS outcome.

Regards,
Alejandro


> This little bit of functionality works on any version of FreeRADIUS (regardless of whether it has RADSEC and trust_router support or not).
>
> With Regards
>
> Stefan
>
>
> -----Original Message-----
> From: Moonshot community list [mailto:[log in to unmask]] On Behalf Of Alejandro Perez Mendez
> Sent: 13 June 2013 10:45
> To: [log in to unmask]
> Subject: SSH and authorization
>
> Hello,
>
> I have some doubts related on how the Moonshot's SSH server is managing authorization. I will use the term username to refer to the identifier in .gss_eap_id (e.g. [log in to unmask]), while I will use the term account to the refer to the account in the SSH server  (i.e. alex@sshserver).
>
> On my first tries, gss_userok failed no matter which username/account combination I tried. I even created the [log in to unmask] account in the server machine, with no luck.
>
> Digging into the mailing list archive, I read about the <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" id="local-login-user"/> option in attribute-map.xml file. That made the trick. Now gss_userok succeed when the account name matched the attribute
> urn:oid:1.3.6.1.4.1.5923.1.1.1.7 included in the SAML Asssertion from the server.
>
> Now, my question is: how can I map the local-login-user attribute to the User-Name attribute from the Access-Accept? Moreover, can I make that map to be hard-coded in the SSH server, in such a way that it does not matter who you are, you will be ending up in the guest@server account. I need these options for the situations where the AAA server is not sending a SAML Assertion (e.g. eduroam AAA server with no moonshot support).
>
> Best regards,
> Alejandro