Hi,
I have a SATOSA use case where the SAML SP that is receiving the
assertion from the SATOSA IdP needs to consume a NameID with format
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
with a particular (non-standard) value.
Has anyone done this with SATOSA? If so, my questions are:
1) What is required for the SAML2 frontend configuration?
2) What is required for the metadata of the consuming SP?
3) What do I need to do, say in a microservice, to populate the value?
If the 'unspecified' format is not possible, I might also be able to
leverage the format
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Has anyone used that format for the NameID asserted to the consuming
SP?
Thanks,
Scott
I wrote:
> I have an instance of SATOSA deployed using mod_wsgi. The BASE
> variable in proxy_conf.yaml is set to something like
> `https://federation.example.com/satosa`. Everything works until my
> test IdP returns the SAML authentication response to SATOSA at
> `https://federation.example.com/satosa/Saml2/acs/post`, where it
> returns a 404 error.
SATOSA's URL routing code constructs regular expressions in ways that assume BASE is just a hostname, like this:
https://federation.example.com
Since I want to co-locate SATOSA with COmanage Registry on the same virtual host in this particular deployment, I used WSGIScriptAliasMatch to bypass non-SATOSA URLs:
WSGIScriptAliasMatch ^/(?!(Shibboleth\.sso|registry|img|css|js|favicon.ico|error.html)) /opt/satosa/lib/python3.6/site-packages/satosa/wsgi.py
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hey everyone,
This isn't a "how does it work" question but rather "it's broke and I
don't know why". Please let me know if this is off-topic here.
I have an instance of SATOSA deployed using mod_wsgi. The BASE variable
in proxy_conf.yaml is set to something like
`https://federation.example.com/satosa`. Everything works until my test
IdP returns the SAML authentication response to SATOSA at
`https://federation.example.com/satosa/Saml2/acs/post`, where it returns
a 404 error. In the logs, I see the following:
[Thu Feb 22 16:47:49.219942 2018] [wsgi:error] [pid 9824] [remote ...]
[2018-02-22 16:47:49,219] [DEBUG] [satosa.proxy_server]: unpack_post::
{'RelayState': '...', 'SAMLResponse': '...'
[Thu Feb 22 16:47:49.231630 2018] [wsgi:error] [pid 9824] [remote ...]
[2018-02-22 16:47:49,231] [DEBUG] [satosa.state]:
[urn:uuid:3bb9c05d-b665-4c23-9a89-8affc05d4574] Loading state from
cookie: SATOSA_STATE='...'; ...
[Thu Feb 22 16:47:49.231816 2018] [wsgi:error] [pid 9824] [remote
10.63.1.38:51166] [2018-02-22 16:47:49,231] [DEBUG] [satosa.routing]:
[urn:uuid:3bb9c05d-b665-4c23-9a89-8affc05d4574] Routing path:
Saml2/acs/post
What am I missing? How do I go about troubleshooting this further?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Oh, sorry my reply only went to Janusz.
But while letting all you others also see my answer I’d like to add that I’d like to
rewrite the OIDC frontend to SATOSA.
It’s now base on pyOP which not readily extensible.
I’d rather use the pyoidc next generation now being worked on
(you can find it as oicmsg, oiccli and oicrp on https://github.com/identitypython)
If we where to switch to nextgen, adding support for PKCE to SATOSA would just be
configuration.
There are still some work needed on nextgen, so no change in the near future.
> Begin forwarded message:
>
> From: Roland Hedberg <roland at catalogix.se>
> Subject: Re: [satosa-users] PKCE support
> Date: 1 December 2017 at 19:51:29 CET
> To: Janusz Ulanowski <janusz.ulanowski at heanet.ie>
>
>
>
>> On 1 Dec 2017, at 15:59, Janusz Ulanowski <janusz.ulanowski at heanet.ie> wrote:
>>
>> Hi,
>> Just curious. Will be PKCE supported in oidc-frontend?
>
> If it’s not there right now it will be added.
> pyoidc has support for it so it should not be that hard.
>
> — Roland
>
We have to send asssertions with emailAddress nameids. This is for a saml
frontend and oidc backend. For now I'm using local patched code, but I'd
prefer to not do that.
I see a pull request (#137) that suggests it would provide the capability.
It seems to be inactive. Is there any chance of it getting merged?
Thanks,
Jim Fox
Univ. of Washington
Hi,
If you are not using the LDAP attribute store microservice for SATOSA
then this note does not concern you. Otherwise please read on...
An updated SATOSA LDAP attribute store microservice with LDAP
connection pooling will be merged today into the satosa_microservice GitHub
repository at
https://github.com/IdentityPython/satosa_microservices
Note that this is NOT the SATOSA repository. Microservices are being
migrated to a new repository and will only be removed from the main
SATOSA repository as part of the next major SATOSA release. New
development for the microservices, however, is primarily taking place in
the new microservices repository.
The updated LDAP attribute store microservice has new functionality AND
a breaking configuration change.
The new functionality is LDAP connection pooling, which provides
substantially better throughput performance as you would expect.
The breaking configuration change is a result of harmonizing the way
microservices are configured, particularly with respect to default
configurations versus per-SP overrides. See the example configuration at
https://github.com/IdentityPython/satosa_microservices/blob/master/example/…
for details. In short, the default configuration must now be labeled as
such using "" or "default". Per-SP overrides remain the same.
Please let me know if you have any questions or concerns.
Thanks,
Scott K
Hi,
I would like SATOSA to receive a SAML assertion from an IdP and check
for a configured set of asserted attributes such as the REFEDs R&S
bundle. If the configured set of asserted attributes is not present
then SATOSA should redirect the browser to an external "error page" to
manage the situation.
I do not see an existing SATOSA microservice that can implement that
requirement. Am I correct?
The primary_identifier microservice can do that for a single identifier
but not for a set of attributes.
If no such microservice (or combination of microservices) can do that
today, I will probably proceed with writing such a microservice. If you
want to input to the requirements and/or design please let me know.
Thanks,
Scott K
Hello,
Our SP is a Dynamics 365 Portal, S2S as SAML2SAML proxy, backend gets metadata from SWAMID, frontend act as IdP for our portal.
Getting the following error, it always stop at “returning attributes”.
Could it possibly be a problem with self-signed SSL certificate that Microsoft CRM Portal does not accept or is any parties not accepting SHA256?
Or is there anything else that I forgot to configure?
Thanks for any help from you guys. The end of the debug log is below.
Mats
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Routing to frontend: Saml2IDP
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Filter: ['givenname', 'mail', 'edupersontargetedid', 'displayname', 'surname', 'name']
[2017-10-19 13:07:26] [DEBUG]: frontend attribute givenName mapped from givenname
[2017-10-19 13:07:26] [DEBUG]: frontend attribute eduPersonTargetedID mapped from edupersontargetedid
[2017-10-19 13:07:26] [DEBUG]: frontend attribute email mapped from mail
[2017-10-19 13:07:26] [DEBUG]: frontend attribute sn mapped from surname
[2017-10-19 13:07:26] [DEBUG]: frontend attribute cn mapped from name
[2017-10-19 13:07:26] [DEBUG]: frontend attribute displayName mapped from displayname
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] returning attributes {"email": [“XXX.XXX at XXX.XXX.XXX <mailto:XXX.XXX at XXX.XXX.XXX>"], "cn": [“XXX XXX"], "eduPersonTargetedID": [“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"], "sn": [“XXX"], "givenName": [“XXX"], "displayName": ["Mats Liu"]}
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:2daabe4d-92c3-434e-b743-fddd2002878b] Saving state as cookie, secure: True, max-age: 1200, path: /
[2017-10-19 13:07:26] [DEBUG]: read request data: {}
[2017-10-19 13:07:26] [DEBUG]: Did not find cookie named 'SATOSA_STATE' in cookie string ''
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:33b0dd08-5a33-4873-b6d9-1efd3421575b] Routing path: favicon.ico
[2017-10-19 13:07:26] [DEBUG]: [urn:uuid:33b0dd08-5a33-4873-b6d9-1efd3421575b] Unknown backend favicon.ico
