summaryrefslogtreecommitdiff
path: root/README.md
blob: 89aea3358d2d81bc35900b64e8f7d06c5d486c06 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
# Shibboleth IDP version 3 project

# RTFM

From
https://wiki.shibboleth.net/confluence/display/IDP30/Configuration

To configure a new IdP from scratch, you will need to address these areas first:
* Metadata
* Authentication
* Attribute Resolver
* Attribute Filter

If you need to dig into more advanced SAML configuration needs, or need to interoperate with commercial cloud services, you will usually need to tackle these areas:
* SAML NameID Generation
* Profiles and Per-RelyingParty Behavior
* Unsolicited (IdP-initiated) SAML

and more

File installer.properties
Properties written out by the installer and used during upgrades. Scripts may create this ahead of time and feed it in to the installer in order to have a silent install. Deployers are not expected to modify this directly.

# planning
https://shibboleth.net/pipermail/users/2016-July/030260.html
http://shibboleth.1660669.n2.nabble.com/SAML-message-intended-destination-endpoint-did-not-match-the-recipient-endpoint-td7626468.html

We setup a new IdP on the 3.x branch. New hostname, new certificates, new
URL bindings, etc; but responding as the same entityID as the old IdP on
the 2.x version.
...




# Testing

The NORDUnet configuration requires that you can reach `ldap.nordu.net`, so make sure you can reach that. E.g. I need to be on VPN to access it.

Add the following to your `/etc/hosts` file:

```
127.0.0.1 idp.nordu.dev sp.nordu.dev
```

Then you can use docker compose to build and start the containers. 

```
docker-compose -f compose-dev.yml up --build
```

When everything has started you need to add the SP metadata to the IdP, this can be done by running:

```
curl -k https://sp.nordu.dev/Shibboleth.sso/Metadata -o data/idp/metadata/sp-metadata.xml
dokcer-compose -f compose-dev.yml restart shibboleth-docker
```

Now you should be able to navigate to `https://sp.nordu.dev/secure/` where you should be prompted to log in.


# Resources
Links from Jesper Rosenkilde

https://shibboleth.net/products/identity-provider.html
https://github.com/UNINETT/mod_auth_mellon


# Running a docker

## Build
```
docker build -t $(basename $(pwd)) .
```

## Run
```
docker run -p80:80 -p 443:443 --rm -ti $(basename $(pwd))
```

## Interactive shell
```
hlk@bujin:shibboleth-docker$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                NAMES
b2b93c309396        shibboleth-docker   "/docker-entrypoin..."   8 minutes ago       Up 8 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 8080/tcp   eager_borg
```

## Getting shell

```
hlk@bujin:shibboleth-docker$ docker exec -ti b2b93c309396 bash
bash-4.3# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
bash-4.3# hostname
b2b93c309396
```

## Copy files out from container


docker cp `docker ps | cut -f 1 -d ' ' | grep -v "CONTAINER"`:/opt/shibboleth-idp/conf /Users/hlk/projects/shibboleth-docker/conf-from-container

```
docker cp c172ac9afb1b:/opt/shibboleth-idp/conf /Users/hlk/projects/shibboleth-docker/conf-from-container
```



# Changes in v2 to v3

Summary of changes
https://wiki.shibboleth.net/confluence/display/IDP30/ConfigurationFileSummary

# Less changes

Attribute resolver
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration
V2 Compatibility
The overall content and structure is identical to V2.  Sematically, the V3 IdP is nearly 100% compatible with V2 attribute configuration.  All regressions should be reported via our issue tracker.
Some key exceptions are noted below.




# Changes to be made

https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration

If the V2 UsernamePassword login handler was used, the V3 equivalent is the Password flow with the JAAS back-end; a similar JAAS configuration can typically be used, but the most common case (LDAP) is an exception because the underlying LDAP library has changed. By convention this configuration is placed in authn/jaas.config and the legacy-matching "ShibUserPassAuth" login configuration name is used (though this can be changed). The UI for password-based login is no longer strictly JSP-based as in V2, but is now a Web Flow view: this can use Velocity, JSP, or potentially other view technologies. The default login.vm view provided uses Velocity. Using an older login.jsp file will require some changes, although the V2 JSP taglibs for metadata-driven UI information should still work. We recommend modernizing to the use of Velocity, as this is much simpler in most cases.
...
So in short, activate flows with the idp.authn.flows property, transfer JAAS or web.xml and container configuration over, and you should have basic compatibility working, apart from the actual login UI for JAAS-based authentication.

This is used in Nordunet config handler.xml




Source: https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration

During the V2 to V3 upgrade process, the original V2 relying-party.xml file is copied to metadata-providers.xml, to serve as the metadata configuration for the new version. It's strongly advisable after upgrading to update that file by stripping it of the older content and promote the <MetadataProvider> element in it to the root of the file. In the interim all other content in the file except for <MetadataProvider> elements (and any referenced <security:TrustEngine> elements) is ignored.
The following non-relevant trust engine types often found in a legacy relying-party.xml file are ignored if seen and cannot be used for metadata verification:
Chaining
MetadataExplicitKey
MetadataPKIXX509Credential
MetadataExplicitKeySignature
MetadataPKIXSignature
StaticPKIXX509Credential


# Other Links

https://spaces.internet2.edu/pages/viewpage.action?pageId=49841792#LinuxIdentityProviderIdPv3(Centos7
"1. Customize the IdP's Login Page"

http://www.jeesty.com/shibboleth
Description of how Shibd works with Apache


https://github.com/nginx-shib/nginx-http-shibboleth
Maybe a working Nginx with Shibb?

https://shibboleth.net/products/metadata-aggregator.html
Metadata Aggregator provides a command line tool and REST-based web service to support publishers and consumers of metadata.
- kan måske lette noget arbejde med at vedligeholde filer?



https://wiki.shibboleth.net/confluence/display/IDP30/Installation+Directory+and+Configuration+Files
describes the Installation Directory and Configuration Files


https://github.com/malavolti/HOWTO-Install-and-Configure-Shibboleth-Identity-Provider/blob/master/HOWTO%20Install%20and%20Configure%20a%20Shibboleth%20v3.2.1%20on%20Ubuntu%20Linux%20LTS%2014.04%20with%20Tomcat%208%20only.md
a sample config - steps to configure 3.2