Shibboleth IdP using the SUNY SP POC.

coldwaterphewΔιακομιστές

17 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

365 εμφανίσεις

Shibboleth IdP using the SUNY SP POC.

This is a brief attempt to get the Shibboleth Identity Provider (IdP) to authenticate users into the SUNY
Employee Services Portal following, very closely, the instructions found at:

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall

We started the POC with a CentOS 5.5 virtual machine without firewall or SELinux for ease of use, you’ll
obviously want to have them on and properly configured for expected use.

It's in a VM
w/ NAT so
we setup
port forward
ing for ports:

22, 443, 8080, 8443

Translating from

141.254.27.79
-
> 10.0.2.15

note:

the hostname used in the VM
must resolve to the IP above

for port forwarding
, so you'll want to
add in a line to your h
osts file(
C:
\
Windows
\
System32
\
drivers
\
etc
\
hosts
) setting that IP to the hostname,
otherwise it may translate to 127.0.0.1 from the host machine.

Step 1: Install openjdk

Shibboleth doesn’t work with the GNU version of Java, so we need to make sure we’re using a
supported

jdk,
so we install openjdk and set its directory to the java home.

yum
-
y install java
-
1.6.0
-
openjdk.x86_64


Confirm

the directory you're going to make java home has openjdk in it:

/etc/alternatives/jre_1.6.0/bin/java
-
version


Figure
1

looks like open jdk

S
et the java home
, otherwise the shibboleth installer will complain latter on.

export JAVA_HOME=/etc/alternatives/jre_1.6.0



Step 2: Install tomcat & adminapps

The shibboleth identity provider is a java application that runs in the A
pache Tomcat application server,
so we

need to
install
and configure Tomcat

yum

makes everything so easy, we just run:

cd /etc/yum.repos.d

wget
http://www.jpackage.org/jpackage50.repo

yum
-
y
install
tomcat6 tomcat6
-
webapps tomcat6
-
admin
-
webapps

And we have a startable tomcat6 instance, but first we might as well c
reate
an
admin account &
set
the
password:

gedit /etc/tomcat6/tomcat
-
users.xml

add
the

account name and password

after picking something
more secure then Welcome1
:

<user username="admin" password="Welcome1" roles="manager,tomcat,role1"/>

Then we just s
tart up the service:

/sbin/service tomcat6 start

And we can verify it’s running by going to
http://localhost:8080/

in a web browser


Figure
2
: Tomcat up and running

Step 3: Install shibboleth.

Next we need to download shibboleth and configure it to run inside of tomcat. First we’ll
Download the
latest from http://shibboleth.net/downloads/identity
-
provider/latest/ and
unzip to the root directory.

cd /

wget
http://shibboleth.net/downloads/identity
-
provider/latest/shibboleth
-
identityprovider
-
2.3.8
-
bin.zip

un
zip shibboleth
-
identityprovider
-
2.3.8
-
bin.zip

Then we just run the install binary:

cd shibboleth
-
identityprovider
-
2.3.8

./install.sh


The installer really just creates a certificate and keystore, and then unzips some files and puts your
hostname in it

I’m

Choosing the

default path
:

/opt/shibboleth
-
idp/

Using

an appropriate hostname:
w7pd008.sysadmin
.suny.edu

Chose an appropriate password:
Welcome1


The password above is being used to create and secure the keystore, we’ll refer to it later on in step5.

Step 4: Setting endorsed jars for tomcat and setting its memory
usage.

Shibboleth comes with a few .jar files that need to be trusted by tomcat, so we’re going to create and
configure an endorsed directory:


mkdir /etc/tomcat6/endorsed

cp /shibboleth
-
ident
ityprovider
-
2.3.8/endorsed/* /etc/tomcat6/endorsed/

T
hen we can edit the startup script for tomcat

so that it u
se
s

that directory
. W
hile we’re at it
we can
increase the maximum memory java will take up and set the maxpermsize:


gedit /usr/sbin/tomcat6 &


JAVA_OPTS="
-
Xmx999m
-
XX:MaxPermSize=128m"

JAVA_ENDORSED_DIRS="/etc/tomcat6/endorsed"


Figure
3
: as good a place as any for those options.

Step 5: Setting tomcat up with support for SSL SOAP endpoints (8433)

Shibboleth will need a
secure endpoint in tomcat to communicate with service providers, so we’ll
download the connector and configure tomcat. First we make a lib directory for a new .jar


mkdir /etc/tomcat6/lib


Then we
download the dta
-
ssl jar:


wget
https://build.shibboleth.net/nexus/content/repositories/releases/edu/internet2/middleware/security/t
omcat6/tomc
at6
-
dta
-
ssl/1.0.0/tomcat6
-
dta
-
ssl
-
1.0.0.jar


Copy it into our new directory


cp tomcat6
-
dta
-
ssl
-
1.0.0.jar /etc/tomcat6/lib/

Then we edit the /etc/tomcat6/catalina.properties so that the common.loader includes the endorsed
and lib directories

when tomcat starts up.


add in: ,/etc/tomcat6/lib/*.jar,/etc/tomcat6/endorsed/*.jar


Figure
4
: modified catalina.properties with the new locations for the common loader


F
inally we setup a connector for that port in the tomcat se
rver.xml

configuring it to use the java
keystore the shibboleth install created for us with the password we gave it.

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
SSLImplementation="edu.internet2.middleware.security.tomcat6.Dele
gateToApplicationJSSEImplement
ation"

scheme="https"

SSLEnabled="true"

clientAuth="want"

keystoreFile="/opt/shibboleth
-
idp/credentials/idp.jks"

keystorePass="Welcome1" />



Figure
5
: modified server.xml with our new secure connecto
r

S
tep 6: change the tomcat logs to be owned by the tomcat user

Since we’re installing everything as root for this quick proof of concept shibboleth running in the tomcat
server as the user tomcat won’t be able to write logs out unless we

chown tomcat /opt
/shibboleth
-
idp/logs


Latter on we
'll be glad
the logging is working if it can’t parse an xml file.

Step 7: Have tomcat deploy shibboleth.

Now we’re ready to actually deploy our now configured shibboleth java application into the tomcat
application
server, to do that we just add in an .xml file letting it know where shibboleth is located.

gedit /etc/tomcat6/Catalina/localhost/idp.xml &


The new file content in this case is:


<Context docBase="/opt/shibboleth
-
idp/war/idp.war"

privileged="true"

antiRes
ourceLocking="false"

antiJARLocking="false"

unpackWAR="false"

swallowOutput="true" />

restart tomcat

/sbin/service tomcat6 restart


N
ow checking out localhost:8080/idp/profile/Status

will give
a

the two characters 'ok' if it

s
all working
up to this point
.


Figure
6
: ok? Ok! Shibboleth is running!

Step 8: Configure authentication to an LDAP.

Now that shibboleth is deployed out to our tomcat server, and seems to be running we’ll want to do
some more configuration to it so that it
will authenticate users against an LDAP. We start by modifying
t
he handler xml

gedit /opt/shibboleth
-
idp/conf/handler.xml


We can just use the existing

UsernamePassword handler for authentication, but
we

have to add in
'authenticationServletURL=”/Authn/Us
erPassword”'

or it won’t know where to go. I

just paste

in

this,
but have to remember
to delete or comment out the exiting one
.

<ph:LoginHandler xsi:type="ph:UsernamePassword"


jaasConfigurationLocation="file:///opt/shibboleth
-
idp/conf/login.config"


authenticationServletURL="/Authn/UserPassword">

<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:
AuthenticationMethod>

</ph:LoginHandler>



Figure
7
: login handler has been set

next we

need to modify the login.config
that is now referenced by the handler.

Below is what I’m using to have it authenticate against our AD:


edu.vt.middleware.ldap.jaas.LdapLoginModule required

ldapUrl="ldap://ad.sysadmin.suny.edu:389"

ssl="false"

tls="false"

baseDn="CN=Users,DC=sysadmin,DC=suny,DC=edu"

subtreeSearch="true"

userFilter="sAMAccountName={0}"

bindDn="SECRETUSERNAME@sysadmin.suny.edu"

bindCredential="SECRETPASSWORD";



Figure
8
: an authentication source configured


Step 9:

Exchange metadata with OIT.

Now we’re almost ready to actually use our shibboleth identity provider, all we have to do is
exchange
metadata with a service provider. We start by sending an email to
secteam@suny.edu

with the url of
our metadata:
http://w7pd008.sysadmin.suny.edu:8080/idp/shibboleth

along with a couple of notes:


First, t
he out of the box shibboleth SingleSignOnService bindings claim
to be https, but we don't have
anything setup to send ssl trafic
to the box
from 443 onto

tomcat running on port 8080 so those

locations have to be changed from https://hostname to
http://hostname:8080

Then the
<KeyDesc
riptor>'s have to be modified for sysadmins sake so that the first has use=”signing”
and the second has use=”encryption”

Then you're ready to import the metadata from
http://www.suny.edu/fed/idp/metadata

by editing the
relying
-
party.xml


<MetadataProvider xsi:type="HTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"

id="SUNY
-
SP"

metadataURL="https://www.suny.edu/fed/sp/metadata"

/>



Figure
9
: doesn't need to be form
atted nicely, copy and paste works just fine.

Now we restart tomcat

/sbin/service tomcat6 restart


Then once
the metadata has been imported at
system administration we can go to the

test login page
and try it out, we just select our provider from the dropd
own


Figure
10
: the shibboleth login page asking for our ldap credentials



Figure
11
: Successful authentication!

Step 10: Set shibboleth up to send

over attributes from your ldap.

At this point we have the most basic authentication working, our identity provider is affirming to the
system administration service provider that we are indeed one of its users, but it’ not sending over any
attributes like
our sunyPersonID, or email addre
ss, or even our username.

We start by
modifying the attribute
-
resolver.xml
which
will allow us to
have the

eduperson attributes
and a
persistent

username
to send over
instead of
just
a new transient username

every time we

login
.


gedit /opt/shibboleth
-
idp/
conf/attribute
-
resolver.xml



S
imply uncommenting the three large chunks of attribute definitions
at the top
is a good start, after that
we’ll want to add in an

LDAP

to get additional attribute from:




<resolver:DataConnector id="myLDAP" xsi:type="
dc:LDAPDirectory"

ldapURL="ldap://ad.sysadmin.suny.edu:389"

baseDN="CN=Users,DC=sysadmin,DC=suny,DC=edu"

principal="SECRETUSER@sysadmin.suny.edu"

principalCredential="SECRETPASSWORD">

<dc:FilterTemplate>

<![CDATA[

(sAMAccountName=$requestContext.principal
Name)

]]>

</dc:FilterTemplate>

</resolver:DataConnector>


Figure
12
: new LDAP dataconnector setup


Then we

add in a definition of the persistentId as an available attribute, in this case
we

defined it as the
sAMAccountName

from the ldap:



<resolver:AttributeDefinition id="persistentId" xsi:type="Simple"

xmlns="urn:mace:shibboleth:2.0:resolver:ad"

sourceAttributeID="sAMAccountName">

<resolver:Dependency ref="myLDAP"/>

<resolver:AttributeEncoder xsi:type="SAML1StringNameIden
tifier"

xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

nameFormat="urn:oasis:names:tc:SAML:2.0:nameid
-
format:persistent" />

<resolver:AttributeEncoder xsi:type="SAML2StringNameID"

xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

nameFormat="urn:oasis:n
ames:tc:SAML:2.0:nameid
-
format:persistent" />

</resolver:AttributeDefinition>



Figure
13
: get the persistent username from the sAMAccountName




F
inally we
just have to modify the attribute
-
filter so that these attributes are actu
ally released to the
service provider we want to federate with

gedit /opt/shibboleth
-
idp/conf/attribute
-
filter.xml



Here is a quick policy that will release the given name and email address to the system administration
service provider:


<afp:AttributeFil
terPolicy>

<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="SUNY
-
SP" />


<afp:AttributeRule attributeID="givenName">

<afp:PermitValueRule xsi:type="basic:ANY" />

</afp:AttributeRule>


<afp:AttributeRule attributeID="email">

<afp
:PermitValueRule xsi:type="basic:ANY" />

</afp:AttributeRule>


</afp:AttributeFilterPolicy>


And here
is a policy that allows the persistent id to be released to everyone:


<afp:AttributeFilterPolicy id="releasePersistentIdToAnyone">

<afp:PolicyRequirement
Rule xsi:type="basic:ANY" />

<afp:AttributeRule attributeID="persistentId">

<afp:PermitValueRule xsi:type="basic:ANY" />

</afp:AttributeRule>

</afp:AttributeFilterPolicy>



Figure
14
: attribute filter configured for email, given n
ame, and persistent id


Then we restart tomcat one last time and test it out


/sbin/service tomcat6 restart


When we go to the test login page at
https://www.suny.edu/fed/user/testspsso

we now should set the
Name ID Format

to ‘Persistent’.


Figure
15
: SUCCESS!