##Moonshot IdP
To install the diagnostic tools (only needed for testing) and the RADIUSd:
- yum install freeradius krb5-moonshot-devel
+ yum install freeradius krb5-moonshot-devel moonshot-gss-eap
+
Once FreeRADIUS is installed, a source of identity needs to be enabled - either the roaming network in the case of an ORPS, or AD/LDAP/etc for an IdP. For now, we'll just use a flat file. Open _/etc/raddb/users_ and locate the following fragment:
# User-Name = "%{request:User-Name}"
#}
+Finally, set the EAP type in use by moonshot (EAP-TTLS) by editing _/etc/raddb/eap.conf_
+
+ default_eap_type = md5
+
+FreeRADIUS now has a very minimal IdP/ORPS configuration, and can be started with:
+
+ service radiusd restart
+
+
+If you encounter any issues, you can run radius in debug mode to see what is going on internally.
+
+ service radiusd stop
+ radiusd -X
+
+When in debug mode, FreeRADIUS acts as an interactive program, so it should be run on a separate console, or under GNU Screen.
+
+##Moonshot Proper
+First we need a minimal _/etc/radsec.conf_
+
+ dictionary = "/etc/raddb/dictionary"
+
+ realm gss-eap {
+ type = "UDP"
+ timeout = 5
+ retries = 3
+ server {
+ hostname = "127.0.0.1"
+ service = "1812"
+ secret = "testing123"
+ }
+ }
+
+This tells the moonshot SP where to find a RADIUS server for authentication - in this case, we will use the local server just configured.<br />
+Moonshot will ultimately use RADSEC for communicating with the radius server – in which case you would use __transport="TCP"__ in _/etc/radsc.conf_<br />
+Ultimately, the final values depend on the deployment – probably the address, port and secret used by your ORPS.
+
+###gss_eap_id
+
+Next, a file is created in the home directory at _~/.gss_eap_id_ – this is the file that moonshot looks in for credentials.
+The format is very simple – username followed by a password. For now, set it to:
+ steve
+ testing
+
+In a deployment with a GUI, this file is replaced by the Moonshot Identity Selector. It is conceivable in the future that the Identity Selector GUI will be supplemented with a curses-like UI, or other mechanism allowing console usage.
+
+###Shibboleth
+Moonshot uses _libshib_ to parse RADIUS and SAML attributes – SAML assertions can be embedded inside RADIUS responses by the IdP, allowing an ORPS to exercise a very fine-grained authorization policy.
+In the demo we just use a very simple example – mapping the _Chargeable-User-Identity_ to a local user account, but in a real deployment you could map a SAML attribute to the user account just as easily.
+
+Delete _/etc/shibboleth/attribute-map.xml_ and replace it with:
+
+
+ <Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <GSSAPIAttribute name="urn:ietf:params:gss-eap:radius-avp urn:x-radius:89" id="local-login-user"/>
+ </Attributes>
+
+In this case, 89 corresponds to _Chargeable-User-Identity_, which is mapped to _local-login-user_, which sets the local account that the user will be given access to.
+
+To load the moonshot extensions, under the root node in /etc/shibboleth/shibboleth2.xml, add:
+ <Extensions>
+ <Library path="plugins.so" fatal="true"/>
+ </Extensions>
+
+
+Further down the same file, find this line:
+ <AttributeExtractor type="XML" validate="true" path="attribute-map.xml"/>
+
+Directly underneath it, add:
+ <AttributeExtractor type="GSSAPI" validate="true" path="attribute-map.xml"/>
+
+Note that this file is sensitive to the order of statements.
+
+###/etc/gss/mech
+
+This file tells moonshot what encryption options are valid for use with GSS.
+
+ #
+ # Sample mechanism glue configuration for EAP GSS mechanism.
+ #
+ # Any encryption type supported by Kerberos can be defined as the
+ # last element of the OID arc.
+ #
+ eap-aes128 1.3.6.1.4.1.5322.22.1.17 mech_eap.so
+ eap-aes256 1.3.6.1.4.1.5322.22.1.18 mech_eap.so
+
+#Testing Functionality
+
+As mentioned earlier, we will be using the Kerberos test tools to make sure that things are working.
+To start the gss-server, run:
+ /opt/moonshot/sbin/gss-server host@localhost &
+
+There are two ways to start gss-client – the first specifies an encryption method to use by its OID 1.3.6.1.4.1.5322.22.1.18 (as seen in /etc/gss/mech):
+ /opt/moonshot/bin/gss-client -mech "{1 3 6 1 4 1 5322 22 1 18}" 127.0.0.1 host@localhost bar
+
+
+The second uses Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)
+This chooses the "best" mutually-agreeable encryption method for between client and server. To invoke the client using SPNEGO, use:
+ /opt/moonshot/bin/gss-client -spnego 127.0.0.1 host@localhost bar
+
+#Sample Output
+
+ Attribute local-login-user Authenticated Complete
+
+ moonshot
+
+ 6d6f6f6e73686f74
+
+ UID: 501
+ Accepted connection: "steve"
+ Sending init_sec_context token (size=150)...continue needed...
+
+ context flag: GSS_C_MUTUAL_FLAG
+ context flag: GSS_C_REPLAY_FLAG
+ context flag: GSS_C_SEQUENCE_FLAG
+ context flag: GSS_C_CONF_FLAG
+ context flag: GSS_C_INTEG_FLAG
+ "steve" to "host/moonbuildcentos.dev.ja.net", lifetime -1, flags 13e, locally initiated, open
+ Name type of source name is { 1 2 840 113554 1 2 1 1 }.
+ Mechanism { 1 3 6 1 5 5 2 } supports 4 names
+ 0: { 1 2 840 113554 1 2 1 1 }
+ 1: { 1 2 840 113554 1 2 1 2 }
+ 2: { 1 2 840 113554 1 2 1 3 }
+ 3: { 1 2 840 113554 1 2 1 4 }
+ Received message: "testing"
+ Signature verified.
+ NOOP token
projects / devwiki.git / blobdiff