First, look at the mech file in the mech_eap directory of the source tree. Copy this file to /etc/gss/mech (or on Debian/Ubuntu systems /usr/etc/gss/mech). The Debian path is a bug that will be fixed; this page will be updated after.
-Then, create a symlink from /usr/lib/gss/mech_eap.so to the installed mech_eap.so. Are you getting the feeling you're running down some untested code paths here yet?
-
-On Debian systems if you are using the system freeradius libraries make sure /usr/lib/freeradius is in your default linker search path. Perhaps edit /etc/ld.so.conf and run ldconfig. Yes, that too is a bug. If you are not using system freeradius libraries you probably have to do something similar.
-
-Create a valid freeradius dictionary in $prefix/etc/radb/dictionary. This may be a bug as well.
-
-# Configuring Kerberos
-
-Configure Kerberos, you ask? But I'm not using Kerberos!
-True, but the Kerberos library is kind of self-centered at the moment and doesn't believe anyone would ever want to not use Kerberos.
-So, it requires that servers be able to set up Kerberos even if they never use it.
-Please see also a bug.
-So you want something like
-
-Contents of /etc/krb5.conf:
-
- [libdefaults]
- default_realm = YOUR_DOMAIN_ALL_CAPS
-
-Then run ktutil
-
- addprinc --password -p host/hostname.your_domain@YOUR_DOMAIN_ALL_CAPS -k 1 -e aes256-cts
-
-Enter a password of your choice
-
- wkt /etc/krb5.keytab
- quit
-
-Then <code>chmod a+r /etc/krb5.keytab</code>. Note that would be a very bad thing to do if you actually were using Kerberos. It may still be a bad thing to do if you have services enabled that can potentially use Kerberos.
+Then, create a symlink from /usr/lib/gss/mech_eap.so to the installed mech_eap.so. Are you getting the feeling you're running down some untested code paths here yet? Your system may use /usr/lib64/gss, or /usr/lib/architecture-and-os/gss instead.
# Configuring libradsec
cat > $prefix/etc/radsec.conf << EOF
- config gss-eap {
+ realm gss-eap {
type = "UDP"
server {
hostname = "127.0.0.1"
- service = "1820"
+ service = "1812"
secret = "$secret"
}
}
Other XML attributes defined for the <GSSAPIAttribute> element:
-*authenticated="true|false" - allows processing to proceed only if the GSS attribute is authenticated
-*binary="true|false" - treats the GSS attribute as binary-valued
+* authenticated="true|false" - allows processing to proceed only if the GSS attribute is authenticated
+* binary="true|false" - treats the GSS attribute as binary-valued
+
+### Daemon Use
+
+To move processing (and significant startup cost) outside of the GSS server process, you can patch mech_eap as follows:
+
+ --- a/moonshot/mech_eap/util_shib.cpp
+ +++ b/moonshot/mech_eap/util_shib.cpp
+ @@ -417,8 +417,7 @@ gss_eap_shib_attr_provider::initWithJsonObject(const gss_eap
+ bool
+ gss_eap_shib_attr_provider::init(void)
+ {
+ - if (SPConfig::getConfig().getFeatures() == 0 &&
+ - ShibbolethResolver::init() == false)
+ + if (ShibbolethResolver::init(SPConfig::InProcess) == false)
+ return false;
+
+ gss_eap_attr_ctx::registerProvider(ATTR_TYPE_LOCAL, createAttrContext);
+
+The shibresolver library also has to be loaded as an extension (exact path and filename vary by platform):
+
+ <OutOfProcess logger="shibd.logger">
+ <Extensions>
+ <Library path="plugins.so" fatal="true"/>
+ <Library path="/usr/lib/libshibresolver.so" fatal="true"/>
+ </Extensions>
+ </OutOfProcess>
+
+If you then run shibd, mech_eap's use of the SP will be remoted to it in the usual fashion.
projects / devwiki.git / blobdiff