- satosa-users - lists3.sunet.se

precedence list for user id internal attribute

by Peter Brand

TL;DR: How can I get SaToSa to select one attribute's value from a list of attribute names, not all of which may be present? Ivan's recommendation from PR 222 doesn't work for me: https://github.com/IdentityPython/SATOSA/pull/222#issuecomment-533238061 Context: I'm trying to use SaToSa as a SAML SP registered in a saml2int identity federation (SAML2 backend module plugin) protecting a bunch of OIDC RPs (openid connect frontend module plugin). In the field not all SAML IDPs support all of the common identifier attributes: Some may only support e.g. eduPersonPrincipalName while others will also (or in an hypothetical future maybe: only) support the "new" SAML standard identifier attributes Subject-ID and/or Pairwise-ID. (And while I could hard-code 'eppn' as the lowest common denominator for everyone that would nullify any benefits the new standard identifier attributes might offer.) FWIW, the Shibboleth SP calls its own support for this the REMOTE_USER precedence list: The first attribute from a list of given attribute names that has a value is chosen as the value for REMOTE_USER. Implementing Ivan's recommendation from PR 222 (link above) doesn't work for me, though. This fails: attributes: id: openid: [sub] saml: [subject-id, pairwise-id, eppn] eppn: openid: [eppn] saml: [eduPersonPrincipalName] user_id_from_attrs: [id] The relevant log lines being: skipped backend attribute ['subject-id', 'pairwise-id', 'eppn']: no value found backend attribute ['eduPersonPrincipalName'] mapped to eppn (['foo(a)example.org']) ... KeyError: 'id' [ERROR] [satosa.proxy_server.__call__] Unknown error I.e., eppn is available/mapped but generating the userid from the 'id' attribute fails, seemingly because there is no 'id' attribute because according to SaToSa the list ['eppn', 'subject-id', 'pairwise-id'] has "no value found". The available behaviour is unhelpful in two regards, AFAICT: https://github.com/IdentityPython/SATOSA/pull/222#issuecomment-533240357 * It implements "all those attributes need to have a value (what currently happens)" (Ivan's words from PR 222) when I've only ever needed "at least one of these attributes needs to have a value" in over a decade of running federations and federated services. * The attributes I care about and would list as possible attribute names are also *not* mutually exclusive, i.e., there may be none (failure), some or all of them available from an IDP. In any case I'd want the user id to only ever have the value of **one** such attribute at maximum, even if multiple attributes may have values. TBH, I can't see how the documented behaviour: https://github.com/IdentityPython/SATOSA/tree/master/doc#user_id_from_attrs > The attribute values of the attributes specified in this list will > be concatenated and used as the subject identifier. could ever be useful to anyone? What good would be the concatenation of multiple attributes' values (e.g. ['subject-id', 'pairwise-id', 'eppn']) provided several of them were available? "foobar@example.orgFOO987654321@example.orgFOO@example.org" Whereas from my experience it's often necessary to support multiple "acceptable alternatives" (different attributes for essentially the same purpose/data) and therefore desireble to have the software pick *one* attribute's value(s) from an ordered-by-preference list. E.g. given ['subject-id', 'pairwise-id', 'eppn'] that would try subject-id, then pairwise-id, then eppn and the first one that has a value would be the one attribute whose values we'd return. (I'd fail if none of the above were present/had a value.) Is there a way to get that behaviour? I'm probably biased but to me that would make a much saner default behaviour than what's available now. Best regards, -peter

10 months, 1 week

1
0
0 0

Unknown attribute name when visible in Attribute Statement

by taylorhucker＠gmail.com

I am writing to request assistance with releasing a custom attribute that is not listed as a requested attribute by one of our InCommon Service Providers (SPs). The attribute is present in the IDP response, but it appears that it is not being returned to the InCommon SP. I have attempted to set the attribute as default for all SPs, but I would like to limit its release to specific SP if needed. I have made some changes to the configuration files and observed the following log messages: Filter: ['edupersonprincipalname', 'edupersonaffiliation', 'givenname', 'edupersonscopedaffiliation', 'mail', 'edupersontargetedid'] Attribute Statement: <ns0:AttributeStatement xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <ns0:Attribute FriendlyName="abcID" Name="urn:oid:1.3.6.1.4.18941.1.2.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">8989898</ns0:AttributeValue></ns0:Attribute> <ns0:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">99999</ns0:NameID></ns0:AttributeValue></ns0:Attribute></ns0:AttributeStatement> Unknown attribute name: <ns0:Attribute xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" FriendlyName="abcID" Name="urn:oid:1.3.6.1.4.18941.1.2.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">8989898</ns0:AttributeValue></ns0:Attribute> skipped backend attribute ['abcID']: no value found I have made the following changes to the configuration files: Internal_attributes.yaml Added abcid: saml: [abcID] Backend.yaml Added custom_attribute_release: "default": include: ["abcID"] allow_unknown_attributes: true attribute_map_dir: [/etc/satosa/attributemaps] Frontend.yaml -No specific changes made Saml_url.py From area: 'urn:oid:1.3.6.1.4.18941.1.2.1.1': 'abcID', To area: 'abcID': 'urn:oid:1.3.6.1.4.18941.1.2.1.1', Could you please help me troubleshoot this issue and provide guidance on how to release the custom attribute as needed? Also how could I release this attribute as the NameID for just the specific SP that requires it?

11 months, 2 weeks

1
1
0 0

saml metadata refresh

by Peter Brand

When configuring a saml2 frontend or backend plugin with remote metadata (url, cert) will that metadata be automatically regularly refreshed from the configured url? If yes, is the purpose of the metadata reload endpoint (which can be enabled with enable_metadata_reload) solely to reload that metadata immediately instead of automatically refreshing it later? (I.e., nice to have but not essential.) If no, does that mean I'll always have to set enable_metadata_reload to a truthy value *and* protect that URL with web server ACLs (to avoid having my service DoS'ed remotely by triggering reload of remote metadata) *and* have to implement a cronjob or systemd timer that regularly accesses the metadata reload endpoint? I don't find anything that would trigger automatic metadata refresh in satosa, so I guess that must come from pysaml2. There's a statement in pysaml2/docs/howto/config.rst about metadata refresh when using MDQ but nothing about aggregates (metadata.remote.url). I see a reload() function defined in pysaml2/src/saml2/mdstore.py but I basically only see that being used in saml2.Entity and the changelog for 7.1.1 says "This method is to be externally invoked". Any pointers? -peter

11 months, 3 weeks

1
0
0 0

idp discovery and multi-tenancy

by Peter Brand

I have deployed Satosa with a saml2 backend (SP) plugin loading multiple IDPs via remote metadata and oidc "frontend" (OP) plugin with currently one configured RP (client_db_path). Now it seems the ressource/application to be protected (using OIDC) may be more of a multi-tenant system, meaning there are separate application instances (to be connected to the OIDC OP side), exactly one per SAML IDP hooked up to Satosa on the saml2 backend side. I.e., each SAML IDP has its own OIDC RP. So a given application instance / OIDC RP would send an OIDC authn req to Satosa as OP (single frontend, configured and shared across all RPs) and that would invoke a single saml2 backend to send SAML authn reqs to the various IDPs known via remote metadata. It seems to me that a single Satosa instance with a single oidc frontend and a single saml2 backend should be able to handle this just fine, by merely adding all applications as individual OIDC RPs (and all IDPs to the remote metadata)? There's nothing "multi-tenanty" about such a setup, yet: Just multiple OIDC RPs and SAML IDPs sharing a single protocol converting proxy. I think the next piece missing then would be avoiding SAML IDP Disovery, since this information could already be derived from each application/RP/client_id, so asking the subject should be avoided. Would anyone have a suggestion on how to achieve this? I can assign client_id values as needed so with carefully chosen values (for automated mapping probably string/regex comparison, for manual/explicit/static mapping a dictionary object) it should be possible to get from OIDC RP (client_id) to SAML IDP (entityID) without having to involve the subject? Best regards, -peter

12 months

1
1
0 0

avoiding saml idp discovery w/ multiple idp remote metadata

by Peter Brand

Can I (pre-)select a single/specific IDP to use with a saml2 backend plugin even if that backend loads multiple IDPs from remote metadata? The documentation[1] seems to say that I can't avoid IDP Discovery whenever multiple IDPs are available: > To allow the user to choose which target provider they want to > authenticate with, the configuration parameter disco_srv, must be > specified if the metadata given to the backend module contains more > than one IdP. (Why load multiple IDPs from remote metadata then when you want to avoid IDP Discovery? Because those IDPs may be available in remotely managed and regularly re-signed metadata. And there's no MDQ service available to hand out an up-to-date, signed copy of only a single IDP for Satosa to consume.) Related to this question: Setting the 'idp' configuration parameter in service -> sp within the saml2 backend plugin (as shown in the pysaml2 docs[2]) resulted in no observable change for Satosa (running 8.4.0 from the official docker image). Is that to be expected? Other parameters from pysaml2 are included in Satosa's saml2 backend plugin at the same level as the 'idp' parameter, e.g. 'authn_requests_signed'. But maybe I'm imagining a relationship here between Satosa and pysaml2 config parameters that doesn't exist? ```yaml``` module: satosa.backends.saml2.SAMLBackend name: sp config: sp_config: service: sp: idp: ['https://idp.example.org/entity'] ``` Anyway, here's the behaviour I (don't) see: With exactly one IDP as list member (as in the YAML above and also the pysaml2 docs[2]) this did not circumvent IDP Discovery as I had expected and would have been useful: With only a single IDP allowed there's no point in offering other IDPs to the subject. (See above for why it may be useful to have multiple IDPs known via metadata but still circumvent IDP discovery by configuration.) But also when configuring one IDP (still as per above) and picking *another* IDP during IDP Discovery access to the configured RP (oidc frontend) was granted just the same. I.e., I could not determine how the selected IDP was somehow "not allowed to be used" (as per the pysaml2 docs, not Satosa's). So unless I'm Doing Things Wrong™ it seems there's no use being made of the 'idp' parameter within the SAML SP config (saml2 backend plugin) within Satosa? If so, could or should there be? Best, -peter [1] https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#use-a-di… [2] https://pysaml2.readthedocs.io/en/latest/howto/config.html#idp

1 year

1
0
0 0

Override to Release All Attributes

by bryan.l＠fischeridentity.com

We have an Incommon Application that is sending a list of three (3) requested attributes. Even though KeyCloak is passing all of the attributes we have configured, once it is filtered out by Satosa it is only passing on the attributes that the actual SP from InCommon requested. Is there a way to override this?

1 year, 3 months

2
2
2 0

SAML2-SAML2 proxy connected to federation: Hardcode different IDPs

by Jonas Schwab

Dear everyone, I have a working SAML2-SAML2 proxy accessing the DFN-AAI, using the DFN-AAI WAYF. This works as expected. Now I was wondering if it is possible to add additional frontends, where each frontend has a DFN-AAI IDP hardcoded it directly proxies to? Thank you for your help! Best regards, Jonas Schwab

1 year, 5 months

1
0
0 0

configuration error: unknown system entity

by Jonas Schwab

Dear all, I am currently trying to set up a saml2-saml2 proxy and have come to an impasse: It seems that I have incorrectly/incompletely set up the frontend. When trying to log in satosa logs "configuration error: unknown system entity <entityID of SP>". I thought the entityID would be set in the frontend plugin configuration through config.idp_config.metadata.local = <file containing SP metadata>. Do I have to set the SP entityID somewhere else? Thank you for your help! Best regards, Jonas Schwab

1 year, 5 months

2
2
0 0

satosa-oidcop and the OIDC Playground

by xenophon＠irtnog.org

I'm trying to test my SATOSA OIDC OP using the OpenID Connect Playground, but it looks like the client isn't registering itself with SATOSA properly. I don't know how to fix this and would be grateful for any help! I have installed satosa-oidcop (https://github.com/UniversitaDellaCalabria/SATOSA-oidcop) and configured it to use Amazon DocumentDB (MongoDB-compatible). On https://openidconnect.net/: - I select the "OpenID Connect + OAuth2" mode (default and only option). - I click "Configuration". - I select the "Custom" server template. - I enter the discovery document URL generated by SATOSA ($BASE_URL/.well-known/openid-configuration), click "Use Discovery Document", and click "Save". The configuration tool sets the authorization token endpoint to $BASE_URL/Saml2/OIDC/authorization, the token endpoint to $BASE_URL/OIDC/token, and the token keys endpoint to $BASE_URL/OIDC/jwks. This looks correct. The configuration tool tells me to set "https://openidconnect.net/callback" as an allowed callback within my application, and it shows me its OIDC Client ID, OIDC client secret, scopes (defaults to "openid profile email phone address"), and optional audience (blank). When I click "Start" to begin the OIDC authentication process, I get the following error: https://openidconnect.net/callback?error=invalid_request&error_message=Resp…... SATOSA logs the following at client configuration time: ``` [DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:..1] Routing path: .well-known/openid-configuration [DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:..1] Unknown backend .well-known [DEBUG] [satosa.routing._find_registered_endpoint_for_module] [urn:uuid:..1] Found registered endpoint: module name:'OIDC', endpoint: .well-known/openid-configuration Then it logs the following when I start the OIDC request process: ``` [ERROR] [pyop.request_validator.response_type_is_in_registered_response_types] client metadata is missing response_types [ERROR] [satosa.frontends.openid_connect._handle_authn_request] [urn:uuid:..2] Error in authn req: Response type is not registered ``` When I look at DocumentDB, I see the "satosa" database and accompanying collections, but the clients collection appears to be empty: ``` rs0:PRIMARY> show dbs sample_database 0.000GB satosa 0.000GB rs0:PRIMARY> use satosa switched to db satosa rs0:PRIMARY> show collections access_tokens authz_codes clients refresh_tokens subject_identifiers rs0:PRIMARY> db.clients.find() rs0:PRIMARY> ``` What am I missing? -- "The reason that ed is the standard editor is to remind you that things could be worse, and once were." -- Tim Lavoie in comp.lang.lisp

1 year, 5 months

3
2
0 0

Updated Docker Official Image for SATOSA

by xenophon＠irtnog.org

Dear all, I’m pleased to announce a long overdue update to the Docker Official Image for SATOSA, which includes several significant changes: - SATOSA 8.4 - Python 3.12 - Debian 12 “bookworm” - Alpine Linux 3.19 The updated container image is now available from Docker Hub. For more information, see https://hub.docker.com/_/satosa. Happy holidays! Matthew -- "The reason that ed is the standard editor is to remind you that things could be worse, and once were." -- Tim Lavoie in comp.lang.lisp

1 year, 6 months

1
0
0 0

XML decoding failing for an AuthN Request

by Hannah Short

Hi Satosa users, I’m having trouble with a SAML request being incorrectly inflated/decoded and then failing with the error “invalid signature” (which I think is misleading). I couldn’t see a known issue about this on GitHub. I’m running Satosa 8.2. Has anyone seen this and has a suggestion? Both the good and bad AuthN Requests in the logs below validate fine at https://www.samltool.com/decode.php Example, “bad” encoding from https://sptest.iamshowcase.com/instructions: [1687184930.586361] [2023-06-19 14:28:50] [DEBUG]: read request data: {'SAMLRequest': 'fVFbb4IwFP4rTd/lUrVCIyRsZhmJZkbYHvZWSh1NoGU9ZdvPH6Jm7sXHk+98t3PWwLu2Z9ngGn2Qn4MEh366VgObgAQPVjPDQQHTvJPAnGBFttsy4gWst8YZYVp8Q7nP4ADSOmU0Rk/GCjn5JvjIW5AYoXyTYB7VhNdRTOpFSGkYrZYhJTSIBa9EFR/JPKLVKpSUYpQDDDLX4Lh2CSYBmc8COgvjMlwwErFl8I7RZmykND95Jrhxrgfm+6ruPSGt9kTjn0IT6H0A4/cGHEbZNeSj0TB00hbSfikhXw/bPwno3ajsKd5BY74FB+kJ0/lcwNhjfznMg9K10h/3b1Kdl4A9l+V+tn8pylEBvUkLU+ZxBafrU0o29bUozbNdcTFd+zdIep7+vzP9BQ=='} ... [1687184930.589399] [2023-06-19 14:28:50] [DEBUG]: xmlstr: b'}Q[o\x820\x14\xfe+M\xdf\xe5R\xb5B#$lf\x19\x89fF\xd8\x1e\xf6VJ\x1dM\xa0e=e\xdb\xcf\x1f\xa2f\xee\xc5\xc7\x93\xef|\xb7s\xd6\xc0\xbb\xb6g\xd9\xe0\x1a}\x90\x9f\x83\x04\x87~\xbaV\x03\x9b\x80\x04\x0fV3\xc3A\x01\xd3\xbc\x93\xc0\x9c`E\xb6\xdb2\xe2\x05\xac\xb7\xc6\x19aZ|C\xb9\xcf\xe0\x00\xd2:e4FO\xc6\n9\xf9&\xf8\xc8[\x90\x18\xa1|\x93`\x1e\xd5\x84\xd7QL\xeaEHi\x18\xad\x96!%4\x88\x05\xafD\x15\x1f\xc9<\xa2\xd5*\x94\x94b\x94\x03\x0c2\xd7\xe0\xb8v\t&\x01\x99\xcf\x02:\x0b\xe32\\0\x12\xb1e\xf0\x8e\xd1fl\xa44?y&\xb8q\xae\x07\xe6\xfb\xaa\xee=!\xad\xf6D\xe3\x9fB\x13\xe8}\x00\xe3\xf7\x06\x1cF\xd95\xe4\xa3\xd10t\xd2\x16\xd2~)!_\x0f\xdb?\t\xe8\xdd\xa8\xec)\xdeAc\xbe\x05\x07\xe9\t\xd3\xf9\\\xc0\xd8c\x7f9\xcc\x83\xd2\xb5\xd2\x1f\xf7oR\x9d\x97\x80=\x97\xe5~\xb6\x7f)\xcaQ\x01\xbdI\x0bS\xe6q\x05\xa7\xebSJ6\xf5\xb5(\xcd\xb3]q1]\xfb7Hz\x9e\xfe\xbf3\xfd\x05', relay_state: None, sigalg: None, signature: None Example “good” encoding from https://samltest.id/saml-test/: [1687184991.342228] [2023-06-19 14:29:51] [DEBUG]: read request data: {'SAMLRequest': 'fZHdT4MwFMX/FdL3UejGJs0gwe3BJVPJQB98MaUUaQIt9hY//nv50DgTs7cmPed37j13C6xtOpr0tlYn8doLsM5H2yig00eEeqOoZiCBKtYKoJbTLLk9UuJ6tDPaaq4b5CQAwlip1U4r6FthMmHeJBcPp2OEams7oBiPRDsEuLLEWS2LQjfC1i6AxiOS4PQ+y5GzHyRSsZH265Vl53JhlMvriUOgw6PRiFIawS1yDvsIPa+qDd+EVyUjgR/6q6AI+bJaE1IUPqlKLxhkAL04KLBM2QgRjywX3nrhh7m/oiSkgf+EnPR7r2upSqleLpdQzCKgN3meLuYVHoWBafxBgOLtODCdgs1ZuZex7KdRFP/X3/jG0G3xGXsO6ujdADvsU91I/ukkTaPfd0YwKyLkIxzPlr8nj78A', 'RelayState': 'ss:mem:a06bd083cf6e2d94f28cccd470c97390dc2ccf20657a3be36e36bce4521e8cdd’} ... [1687184991.345231] [2023-06-19 14:29:51] [DEBUG]: xmlstr: b'<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://samltest.id/Shibboleth.sso/SAML2/POST" Destination="https://idp.cern.ch/saml2sp/sso/redirect" ID="_4f7c798da2519145b9c3f622bb12fd05" IssueInstant="2023-06-19T14:29:51Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://samltest.id/saml/sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>', relay_state: None, sigalg: None, signature: None Thanks for any help! Hannah

2 years

2
2
0 0

Loading custom modules as satosa microservcies in docker

by canni2007＠gmail.com

Dear satosa users, I'm running the debian docker of satosa v8.2 and tried setting CUSTOM_PLUGIN_MODULE_PATHS in proxy_conf.yaml in order to load custom modules (microservices). I would like to mount the microservices from the docker host. I tried relative paths and absolute paths within the docker container but satosa raises a ValueError that it cannot find the modules. I could mount them like this "./modules/custom_service.py:/usr/local/lib/python3.11/site-packages/satosa/micro_services/custom_service.py" but I'd prefer to mount them with the configuration folder /etc/satosa/ or in a similar way Anyone got a clue how to load custom microservices with the option? Regards canni

2 years, 1 month

2
3
0 0

SATOSA as podman Pod

by Stephan Krinetzki

Since the documentation could not really help me, I now asked by e-mail: I already have SATOSA running successfully in a pyenv and would now like to run the whole thing in a container on another host. However, I fail already when starting the container. I use Rocky Linux 9 and podman, my configuration is under /home/satosa/application. In addition to the plugin folder, there is also a folder for the metadata and the attribute map. The certificates for the saml2 frontend and backend are in the certs directory. What do I have to bear in mind when starting the container? And another question: I am looking for a plugin that denies users access to the application behind the proxy if certain attributes are missing. Is there already something available? Any help is appreciated. Regards Stephan Stephan Krinetzki IT Center Gruppe: Anwendungsbetrieb und Cloud Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki(a)itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ

2 years, 2 months

2
1
0 0

SATOSA as podman Pod

by Stephan Krinetzki

Since the documentation could not really help me, I now asked by e-mail: I already have SATOSA running successfully in a pyenv and would now like to run the whole thing in a container on another host. However, I fail already when starting the container. I use Rocky Linux 9 and podman, my configuration is under /home/satosa/application. In addition to the plugin folder, there is also a folder for the metadata and the attribute map. The certificates for the saml2 frontend and backend are in the certs directory. What do I have to bear in mind when starting the container? And another question: I am looking for a plugin that denies users access to the application behind the proxy if certain attributes are missing. Is there already something available? Any help is appreciated. Regards Stephan Stephan Krinetzki IT Center Gruppe: Anwendungsbetrieb und Cloud Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki(a)itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ

2 years, 2 months

1
0
0 0

Help to implement Satosa + Keycloak + Edugain

by U W

Hello everyone, My company develops a web application that uses Keycloak to authenticate / manages users. We would like to accept authentication from Edugain but Edugain is not only one federation: it is an interconnection of many federations. Therefore, if I want to accept Edugain it means I have to import one by one each Edugain Federation and our end users have to choose the right one in a list. Example: - if I have these Edugain federations: - Federation A - Federation B - Federation C - Federation D - I have to import / create an identity provider for each one in Keycloak: - Federation A - Federation B - Federation C - Federation D - the end user has to choose the Edugain Federation in which he/she has an account: Federation C This is not a good option in term or ergonomy because there are too many federations... I discovered Satosa and maybe I'm wrong (as I was not able to implement it yet) but I have the feeling it could help us 🙂 The scheme I try to obtain is: our internal application -> Keycloak -> Satosa -> Edugain The idea is this one: - Keycloak should see only one Identity Provider 'Edugain': in reality it is Satosa behind - and Satosa discovers the Edugain federations I'm not comfortable with these technologies / these protocols (Keycloak, Satosa, SP, IDP, SAML, etc) and therefore I don't understand how to configure all components... Is this someone did the same (Keycloak or Gluu + Satosa + Edugain) and could share with me an example of configurations please? At least the Satosa configuration files (frontend, backend, etc). Thank you very much :) Bertrand

2 years, 4 months

4
11
0 0

skipped backend attribute ['email', 'emailAddress', 'mail']: no value found

by eric.attou＠wacren.net

Hello, I am deploying SaToSa version 8. But, it seems that the backend module is failing to map attribute from the IdP to internal proxy attributes. In fact, after the user's is authenticated, and accepted the consent, i got : KeyError 'mail' in the satosa log. What should i have missed in the configs ? Below is part of the log 2022-09-09 20:04:11,840] [DEBUG] [satosa.attribute_mapping.to_internal] skipped backend attribute ['email', 'emailAddress', 'mail']: no value found satosa-proxy_1 | [2022-09-09 20:04:11,840] [DEBUG] [satosa.attribute_mapping.to_internal] skipped backend attribute ['cn']: no value found satosa-proxy_1 | [2022-09-09 20:04:11,841] [DEBUG] [satosa.attribute_mapping.to_internal] skipped backend attribute ['sn', 'surname']: no value found satosa-proxy_1 | [2022-09-09 20:04:11,841] [DEBUG] [satosa.attribute_mapping.to_internal] skipped backend attribute ['eduPersonScopedAffiliation']: no value found satosa-proxy_1 | [2022-09-09 20:04:11,841] [DEBUG] [satosa.attribute_mapping.to_internal] skipped backend attribute ['eduPersonPrincipalName']: no value found satosa-proxy_1 | [2022-09-09 20:04:11,842] [DEBUG] [satosa.backends.saml2._translate_response] [urn:uuid:722089a1-b43e-47b0-bd98-2888c96b3a10] backend received attributes: satosa-proxy_1 | {} satosa-proxy_1 | [2022-09-09 20:04:11,842] [ERROR] [satosa.base.run] [urn:uuid:722089a1-b43e-47b0-bd98-2888c96b3a10] Uncaught exception satosa-proxy_1 | Traceback (most recent call last): satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 240, in run satosa-proxy_1 | resp = self._run_bound_endpoint(context, spec) satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint satosa-proxy_1 | return spec(context) satosa-proxy_1 | File "/src/satosa/src/satosa/backends/saml2.py", line 363, in authn_response satosa-proxy_1 | return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 141, in _auth_resp_callback_func satosa-proxy_1 | subject_id = [ satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 142, in <listcomp> satosa-proxy_1 | "".join(internal_response.attributes[attr]) for attr in satosa-proxy_1 | KeyError: 'mail' satosa-proxy_1 | [2022-09-09 20:04:11,843] [ERROR] [satosa.proxy_server.__call__] Unknown error satosa-proxy_1 | Traceback (most recent call last): satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 240, in run satosa-proxy_1 | resp = self._run_bound_endpoint(context, spec) satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint satosa-proxy_1 | return spec(context) satosa-proxy_1 | File "/src/satosa/src/satosa/backends/saml2.py", line 363, in authn_response satosa-proxy_1 | return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 141, in _auth_resp_callback_func satosa-proxy_1 | subject_id = [ satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 142, in <listcomp> satosa-proxy_1 | "".join(internal_response.attributes[attr]) for attr in satosa-proxy_1 | KeyError: 'mail' satosa-proxy_1 | satosa-proxy_1 | The above exception was the direct cause of the following exception: satosa-proxy_1 | satosa-proxy_1 | Traceback (most recent call last): satosa-proxy_1 | File "/src/satosa/src/satosa/proxy_server.py", line 148, in __call__ satosa-proxy_1 | resp = self.run(context) satosa-proxy_1 | File "/src/satosa/src/satosa/base.py", line 258, in run satosa-proxy_1 | raise SATOSAUnknownError("Unknown error") from err satosa-proxy_1 | satosa.exception.SATOSAUnknownError: Unknown error

2 years, 9 months

2
1
0 0

Installing Satosa under a location

by Kristof Bajnok

Hi all, I need to install Satosa under a path instead of the root of the webserver, but I can not make endpoint routing work if BASE in proxy_conf.yaml contains a path (ie. "https://example.com/path"). For long I was thinking it was a configuration error on my side, but I realised that also the flow (unit) tests fail if I change the BASE to such a value. I've filed a bug under https://github.com/IdentityPython/SATOSA/issues/404, and I'm already more than halfway fixing it, but I still can hardly believe that everybody installs Satosa under "/". Rewriting the request in the webserver breaks metadata generation, because it needs to know the external URLs and not the rewritten ones. It is a possibility to run metadata generation with a slightly different configuration file, but I'd like to avoid maintaining two sets of configurations if possible. Has anybody run into a similar issue? Kristof

2 years, 11 months

1
0
0 0

[Zeek] Zeek is not always detecting outcome of SSH connections.

by kuba.michal.n＠gmail.com

Hello, after completing another project I had some time to dig into the issue a little bit deeper. I've come across this site: https://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full… I turns out my interface was misconfigured. Disabling some offloads solved the issue and overall loss has dropped significantly. Thank you for your help! Jakub czw., 2 wrz 2021 o 16:02 Vlad Grigorescu <vlad at es.net> napisał(a): > Jakub, > > Sorry for the delay on this, I was also out and then it fell off my radar. > > I think your answer lies in the missed_bytes field of the conn log. All of > the connections from your ssh.log had traffic that Zeek did not see. Since > Zeek has no way of knowing what transpired in those missed bytes, the SSH > analyzer will never flag those connections as successful or failed. > > The mailing list or Slack might have some suggestions on how to determine > the cause of your missed bytes, and what the solution might be. > > --Vlad > > On Thu, Aug 19, 2021 at 9:58 AM Jakub Niezabitowski < > kuba.michal.n at gmail.com> wrote: > >> Hello, >> >> I will be out for about a week. Sorry for your inconvenience. If there >> will be any update I will write as soon as I can. >> >> Thank you for your support. >> Jakub >> >> czw., 19 sie 2021 o 15:25 Jakub Niezabitowski <kuba.michal.n at gmail.com> >> napisał(a): >> >>> This is output of zeek -v: >>> ./zeek version 4.1.0-dev.750 >>> >>> ssh.log: >>> >>> {"ts":1629353969.834005,"uid":"C6vC4b2O0r71ggNi25","id.orig_h":"149.156.4.93","id.orig_p":42814,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629355319.70739,"uid":"C0c0604XfdAEv7svZb","id.orig_h":"149.156.4.93","id.orig_p":42818,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> {"ts":1629355326.102184,"uid":"ClskL8uZ1TVWjwYV5","id.orig_h":"149.156.4.93","id.orig_p":42820,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> {"ts":1629363511.517178,"uid":"CcqehS1QVeUxz1B4Od","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629359395.93802,"uid":"ChjjxO1RDEYWkNATye","id.orig_h":"149.156.4.93","id.orig_p":56826,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629359403.032656,"uid":"CjDb491bXc6cNybmn2","id.orig_h":"149.156.4.93","id.orig_p":56828,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629362225.296699,"uid":"CowriFJduoVFdyFH1","id.orig_h":"149.156.4.93","id.orig_p":35404,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> {"ts":1629361952.911338,"uid":"CFoYi71C4Nh1f5zlLk","id.orig_h":"149.156.4.93","id.orig_p":35402,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629368286.231978,"uid":"CevlPO3R5JgpEwTLfe","id.orig_h":"149.156.4.93","id.orig_p":33266,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.5p1-hpn15v2","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629368323.887805,"uid":"CSSAMgMkKpJnTYDOg","id.orig_h":"149.156.4.93","id.orig_p":33268,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.5p1-hpn15v2","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629368384.265589,"uid":"CszcwObIzxyaFRswi","id.orig_h":"149.156.4.93","id.orig_p":33270,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.5p1-hpn15v2","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629369473.554433,"uid":"C2iNBj2NrOS4TvWqed","id.orig_h":"149.156.4.93","id.orig_p":33272,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.5p1-hpn15v2","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629369478.658333,"uid":"CZLjJa3oSIDiQD0Ko1","id.orig_h":"149.156.4.93","id.orig_p":33274,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.5p1-hpn15v2","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629363611.176921,"uid":"CanhZA2xCTZoDMPvng","id.orig_h":"149.156.4.93","id.orig_p":39666,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> {"ts":1629363530.397083,"uid":"CeYi3U1HCr8ADcerw9","id.orig_h":"149.156.4.93","id.orig_p":39664,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.6","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4"} >>> {"ts":1629366392.592983,"uid":"CuthbE1HzIye71DjVc","id.orig_h":"149.156.4.93","id.orig_p":54438,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.1","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> {"ts":1629365717.892757,"uid":"C9hAYf1UisBCzG2GL5","id.orig_h":"149.156.4.93","id.orig_p":54101,"id.resp_h":"149.156.9.136","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-OpenSSH_8.1","server":"SSH-2.0-OpenSSH_7.4p1c-GSI >>> GSI-hpn14v13-OpenSSH_7.4","cipher_alg":"chacha20-poly1305 at openssh.com >>> ","mac_alg":"umac-64-etm at openssh.com >>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"ecdsa-sha2-nistp256","host_key":"16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd"} >>> >>> conn.log: >>> >>> {"ts":1629353969.732991,"uid":"C6vC4b2O0r71ggNi25","id.orig_h":"149.156.4.93","id.orig_p":42814,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":1343.1681571006776,"orig_bytes":10765,"resp_bytes":1249389,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":372560,"history":"ShADadCGcggctgtcFRf","orig_pkts":2290,"orig_ip_bytes":128761,"resp_pkts":1878,"resp_ip_bytes":1005437} >>> >>> {"ts":1629355322.821648,"uid":"CBGul41OnibExQK9O6","id.orig_h":"149.156.4.93","id.orig_p":42814,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":88.76865911483765,"orig_bytes":0,"resp_bytes":1048,"conn_state":"OTH","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^dt","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":4,"resp_ip_bytes":4400} >>> >>> {"ts":1629355319.682793,"uid":"C0c0604XfdAEv7svZb","id.orig_h":"149.156.4.93","id.orig_p":42818,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":3674.8831601142885,"orig_bytes":5049,"resp_bytes":2136781,"conn_state":"RSTO","local_orig":false,"local_resp":false,"missed_bytes":9868,"history":"ShADadcgttR","orig_pkts":4225,"orig_ip_bytes":225141,"resp_pkts":4243,"resp_ip_bytes":2382129} >>> >>> {"ts":1629355326.076816,"uid":"ClskL8uZ1TVWjwYV5","id.orig_h":"149.156.4.93","id.orig_p":42820,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":3696.138195991516,"orig_bytes":8641,"resp_bytes":2227993,"conn_state":"RSTO","local_orig":false,"local_resp":false,"missed_bytes":47024,"history":"ShADadcggttcGR","orig_pkts":4504,"orig_ip_bytes":243421,"resp_pkts":4411,"resp_ip_bytes":2454697} >>> >>> {"ts":1629363511.478,"uid":"CcqehS1QVeUxz1B4Od","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":26.2694411277771,"orig_bytes":3497,"resp_bytes":45209,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":28080,"history":"ShADadCGcggFRft","orig_pkts":88,"orig_ip_bytes":6557,"resp_pkts":66,"resp_ip_bytes":23653} >>> >>> {"ts":1629363542.919383,"uid":"CpYDAh26XA0tnFjqE8","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","conn_state":"SHR","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^f","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":1,"resp_ip_bytes":576} >>> >>> {"ts":1629363548.264316,"uid":"CKIeJ02kp7bqmZHQGa","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","conn_state":"SHR","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^f","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":1,"resp_ip_bytes":576} >>> >>> {"ts":1629363558.951295,"uid":"Cy70hG3xbe0YraNLQ","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","conn_state":"SHR","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^f","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":1,"resp_ip_bytes":576} >>> >>> {"ts":1629363580.29527,"uid":"ClzNXf3uL9jMAKVFN8","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","conn_state":"SHR","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^f","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":1,"resp_ip_bytes":576} >>> >>> {"ts":1629363623.047142,"uid":"CM6AG64ej3HoBNCmV6","id.orig_h":"149.156.4.93","id.orig_p":39662,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","conn_state":"SHR","local_orig":false,"local_resp":false,"missed_bytes":0,"history":"^f","orig_pkts":0,"orig_ip_bytes":0,"resp_pkts":1,"resp_ip_bytes":576} >>> >>> {"ts":1629359395.898961,"uid":"ChjjxO1RDEYWkNATye","id.orig_h":"149.156.4.93","id.orig_p":56826,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":2406.9871258735659,"orig_bytes":14529,"resp_bytes":1270377,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":231140,"history":"ShADadCGcggtcgTt","orig_pkts":2670,"orig_ip_bytes":152449,"resp_pkts":2337,"resp_ip_bytes":1196833} >>> >>> {"ts":1629359402.915081,"uid":"CjDb491bXc6cNybmn2","id.orig_h":"149.156.4.93","id.orig_p":56828,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":2431.203042984009,"orig_bytes":22009,"resp_bytes":3986829,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":401516,"history":"ShADadCGcgtTtgcGgc","orig_pkts":8571,"orig_ip_bytes":467389,"resp_pkts":8341,"resp_ip_bytes":4070913} >>> >>> {"ts":1629362225.253584,"uid":"CowriFJduoVFdyFH1","id.orig_h":"149.156.4.93","id.orig_p":35404,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":1795.6165931224824,"orig_bytes":23017,"resp_bytes":1719917,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":249976,"history":"ShAdDacggtctTg","orig_pkts":3808,"orig_ip_bytes":221809,"resp_pkts":3676,"resp_ip_bytes":1708085} >>> >>> {"ts":1629361952.865328,"uid":"CFoYi71C4Nh1f5zlLk","id.orig_h":"149.156.4.93","id.orig_p":35402,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":2072.1008388996126,"orig_bytes":27917,"resp_bytes":1165281,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":322496,"history":"ShADadCGcgtTgctgc","orig_pkts":3158,"orig_ip_bytes":191313,"resp_pkts":2439,"resp_ip_bytes":1014905} >>> >>> {"ts":1629368286.226311,"uid":"CevlPO3R5JgpEwTLfe","id.orig_h":"149.156.4.93","id.orig_p":33266,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":31.089575052261354,"orig_bytes":4095,"resp_bytes":7573,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":6016,"history":"ShADadcgCGtFf","orig_pkts":50,"orig_ip_bytes":5807,"resp_pkts":35,"resp_ip_bytes":4377} >>> >>> {"ts":1629368323.882291,"uid":"CSSAMgMkKpJnTYDOg","id.orig_h":"149.156.4.93","id.orig_p":33268,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":39.62539982795715,"orig_bytes":3907,"resp_bytes":7133,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":6016,"history":"ShADadcgCGFf","orig_pkts":38,"orig_ip_bytes":4983,"resp_pkts":26,"resp_ip_bytes":3385} >>> >>> {"ts":1629368384.260782,"uid":"CszcwObIzxyaFRswi","id.orig_h":"149.156.4.93","id.orig_p":33270,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":95.20389604568482,"orig_bytes":4699,"resp_bytes":8045,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":6016,"history":"ShADadcgCGFf","orig_pkts":78,"orig_ip_bytes":7855,"resp_pkts":48,"resp_ip_bytes":5441} >>> >>> {"ts":1629369473.551176,"uid":"C2iNBj2NrOS4TvWqed","id.orig_h":"149.156.4.93","id.orig_p":33272,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":4.286886930465698,"orig_bytes":3907,"resp_bytes":7169,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":5108,"history":"ShADadcgtFf","orig_pkts":42,"orig_ip_bytes":6111,"resp_pkts":29,"resp_ip_bytes":3661} >>> >>> {"ts":1629369478.65472,"uid":"CZLjJa3oSIDiQD0Ko1","id.orig_h":"149.156.4.93","id.orig_p":33274,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":1.974303960800171,"orig_bytes":3907,"resp_bytes":7133,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":6016,"history":"ShADadcgtTCGFf","orig_pkts":39,"orig_ip_bytes":5535,"resp_pkts":27,"resp_ip_bytes":3909} >>> >>> {"ts":1629363611.137711,"uid":"CanhZA2xCTZoDMPvng","id.orig_h":"149.156.4.93","id.orig_p":39666,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":4322.946979999542,"orig_bytes":83385,"resp_bytes":4093093,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":1280948,"history":"ShADadcgcggttcTt","orig_pkts":9754,"orig_ip_bytes":592549,"resp_pkts":7344,"resp_ip_bytes":3280677} >>> >>> {"ts":1629363530.35789,"uid":"CeYi3U1HCr8ADcerw9","id.orig_h":"149.156.4.93","id.orig_p":39664,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":4444.6867852211,"orig_bytes":16493,"resp_bytes":2455029,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":99340,"history":"ShADadCGcgtgctT","orig_pkts":5389,"orig_ip_bytes":295961,"resp_pkts":5126,"resp_ip_bytes":2670001} >>> >>> {"ts":1629366392.574032,"uid":"CuthbE1HzIye71DjVc","id.orig_h":"149.156.4.93","id.orig_p":54438,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":5154.938705921173,"orig_bytes":14113,"resp_bytes":49097,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":17616,"history":"ShADadcgCGgc","orig_pkts":699,"orig_ip_bytes":49321,"resp_pkts":433,"resp_ip_bytes":55169} >>> >>> {"ts":1629365717.871532,"uid":"C9hAYf1UisBCzG2GL5","id.orig_h":"149.156.4.93","id.orig_p":54101,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","service":"ssh","duration":5869.062443971634,"orig_bytes":25417,"resp_bytes":123257,"conn_state":"S1","local_orig":false,"local_resp":false,"missed_bytes":68778,"history":"ShADadcgCGTtgc","orig_pkts":1409,"orig_ip_bytes":97629,"resp_pkts":764,"resp_ip_bytes":96079} >>> >>> {"ts":1629378908.289358,"uid":"CgpvjA2SRGDerkjnt7","id.orig_h":"149.156.4.93","id.orig_p":33276,"id.resp_h":"149.156.9.136","id.resp_p":22,"proto":"tcp","duration":12.938737154006958,"orig_bytes":4699,"resp_bytes":8277,"conn_state":"SF","local_orig":false,"local_resp":false,"missed_bytes":6047,"history":"ShaGADdcgCtFf","orig_pkts":83,"orig_ip_bytes":8127,"resp_pkts":51,"resp_ip_bytes":5913} >>> >>> I also append new pcap in case logs for older one have been already >>> rotated. >>> >>> Jakub >>> >>> czw., 19 sie 2021 o 13:42 Vlad Grigorescu <vlad at es.net> napisał(a): >>> >>>> When I run the PCAP through try.zeek.org, it reports auth_success as >>>> T, https://try.zeek.org/#/tryzeek/saved/527994 >>>> >>>> What version of Zeek? To verify that capture loss isn't an issue, can >>>> you share the line from conn.log that you see for that connection? >>>> >>>> On Thu, Aug 19, 2021 at 5:47 AM Jakub Niezabitowski < >>>> kuba.michal.n at gmail.com> wrote: >>>> >>>>> To add some context this is my node.cfg: >>>>> >>>>> [logger-1] >>>>> type=logger >>>>> host=localhost >>>>> # >>>>> [manager] >>>>> type=manager >>>>> host=localhost >>>>> # >>>>> [proxy-1] >>>>> type=proxy >>>>> host=localhost >>>>> # >>>>> [worker-1] >>>>> type=worker >>>>> host=localhost >>>>> lb_procs=8 >>>>> lb_method=pf_ring >>>>> pin_cpus=0,1,2,3,4,5,6,7 >>>>> interface=eth-mirror >>>>> >>>>> This machine can handle up to 8GBit/s of traffic, during capture it >>>>> was about 1GBit/s. >>>>> >>>>> >>>>> czw., 19 sie 2021 o 12:42 Jakub Niezabitowski <kuba.michal.n at gmail.com> >>>>> napisał(a): >>>>> >>>>>> Hello, >>>>>> >>>>>> The data was gathered on same network interface as zeek. It was >>>>>> filtered though to include only related traffic. >>>>>> >>>>>> I have logged in using host 149.156.4.93 to machine 149.156.9.136 and >>>>>> executed few commands. Zeek is not showing auth_success field. >>>>>> >>>>>> After reading provided docs ( >>>>>> https://docs.zeek.org/en/master/scripts/base/protocols/ssh/main.zeek.html#i…) >>>>>> I assume it could be related to capture losses but it shouldn't. The amount >>>>>> of traffic was way below average. >>>>>> >>>>>> Thank you for your help! >>>>>> Jakub >>>>>> >>>>>> >>>>>> śr., 18 sie 2021 o 14:27 Vlad Grigorescu <vlad at es.net> napisał(a): >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 18, 2021 at 03:27 Jakub Niezabitowski < >>>>>>> kuba.michal.n at gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> {"ts":1629151421.501644,"uid":"CUgRqs4tiJyHemzjs5","id.orig_h":"IP1","id.orig_p":41080,"id.resp_h":"IP2","id.resp_p":22,"version":2,"auth_attempts":0,"client":"SSH-2.0-Go","server":"SSH-2.0-OpenSSH_8.2p1 >>>>>>>> Ubuntu-4ubuntu0.2","cipher_alg":"aes128-gcm at openssh.com >>>>>>>> ","mac_alg":"hmac-sha2-256-etm at openssh.com >>>>>>>> ","compression_alg":"none","kex_alg":"curve25519-sha256 at libssh.org >>>>>>>> ","host_key_alg":"ecdsa-sha2-nistp256","host_key":"KEY1"} >>>>>>>> >>>>>>> >>>>>>> This connection had “auth_attempts: 0,” so there was nothing to make >>>>>>> a determination on. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> {"ts":1629151420.84616,"uid":"CN6Tsq42Ki15BZF9J","id.orig_h":"IP3","id.orig_p":38122,"id.resp_h":"IP4","id.resp_p":22,"version":2,"auth_success":false,"auth_attempts":2,"client":"SSH-2.0-OpenSSH_8.1","server":"SSH-2.0-babeld-322814ef","cipher_alg":" >>>>>>>> chacha20-poly1305 at openssh.com","mac_alg":" >>>>>>>> hmac-sha2-256-etm at openssh.com >>>>>>>> ","compression_alg":"none","kex_alg":"curve25519-sha256","host_key_alg":"rsa-sha2-512","host_key":"KEY2"} >>>>>>>> >>>>>>> This connection has “auth_success: false,” so it seems like a >>>>>>> determination was made? >>>>>>> >>>>>>> The docs ( >>>>>>> >>>>>>> https://docs.zeek.org/en/master/scripts/base/protocols/ssh/main.zeek.html#i…) >>>>>>> have a bit more info, but essentially, yes it is expected, and Zeek goes to >>>>>>> some lengths to avoid false positives and negatives, at the expense of true >>>>>>> positives. However, that doesn’t seem to be the case here? >>>>>>> >>>>>>> —Vlad >>>>>>> >>>>>>

3 years, 9 months

1
0
0 0

Example consent page

by kuba.michal.n＠gmail.com

Hello, does anybody have example consent page for consent plugin for satosa? It would be very helpful. Thank you in advance, Jakub

3 years, 9 months

2
1
0 0

Specify remd:contactType and assert Sirtfi compliance in Satosa frontend metadata

by kuba.michal.n＠gmail.com

Hi, I have updated metadata_tostring_fix function in metadata.py. It's ugly but it gets the job done: ```python def metadata_tostring_fix(desc, nspair, xmlstring=""): if not xmlstring: xmlstring = desc.to_string(nspair) try: if "\"xs:string\"" in xmlstring and XMLNSXS not in xmlstring: xmlstring = xmlstring.replace(MDNS, MDNS + XMLNSXS) except TypeError: if b"\"xs:string\"" in xmlstring and bXMLNSXS not in xmlstring: xmlstring = xmlstring.replace(bMDNS, bMDNS + bXMLNSXS) xmlstring_decoded = xmlstring.decode("utf-8") #JN xmlstring = re.sub(r'(<\/ns0:ContactPerson>)', r'\1<md:ContactPerson xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" contactType="other" remd:contactType="http://refeds.org/metadata/contactType/security" xmlns:remd="http://refeds.org/metadata"><md:GivenName>Security Response Team</md:GivenName><md:EmailAddress>mailto:security at xxxxxxxxxxxxxxx</md:EmailAddress></md:ContactPerson>', xmlstring_decoded) #JN xmlstring = bytes(xmlstring, 'utf-8') #JN return xmlstring ``` czw., 2 wrz 2021 o 16:05 Jakub Niezabitowski <kuba.michal.n at gmail.com> napisał(a): > Hello Ivan, > > thank you for your quick response. Adding assurance_certification works > great! > > czw., 2 wrz 2021 o 15:55 Ivan Kanakarakis <ivan.kanak at gmail.com> > napisał(a): > >> hello Jakub, >> >> ## refeds metadata >> >> the refeds metadata is not known to pysaml2, and thus there is no way >> to do this. >> We can look into adding support and exposing that as part of the >> configuration. >> >> Until that is in place, you can add a post processing rule on your >> deployment proceed to inject the namespace and element as needed. >> >> >> ## assurance certification >> >> To add an assurance certification you can add the following in your >> saml frontend configuration: >> >> ```yaml >> module: ... >> name: ... >> config: >> idp_config: >> ... >> assurance_certification: >> - https://refeds.org/sirtfi >> ... >> ``` >> >> >> On Thu, 2 Sept 2021 at 15:25, Jakub Niezabitowski >> <kuba.michal.n at gmail.com> wrote: >> > >> > Hello, >> > >> > does anybody know how to specify remd:contactType for Satosa front-end? >> It is necessary for Refeds. Example: >> > >> > <md:ContactPerson contactType="other" remd:contactType=" >> http://refeds.org/metadata/contactType/security"> >> > <md:Company>XYZ</md:Company> >> > <md:GivenName>ABC</md:GivenName> >> > <md:SurName>Security</md:SurName> >> > <md:EmailAddress>mailto:security at example.com</md:EmailAddress> >> > </md:ContactPerson> >> > >> > I would be also very thankful for help in adding this static string to >> metadata: >> > >> > <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" >> ...> >> > <md:Extensions> >> > <mdattr:EntityAttributes >> xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> >> > <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" >> > >> Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> >> > <saml:AttributeValue>https://refeds.org/sirtfi >> </saml:AttributeValue> >> > </saml:Attribute> >> > </mdattr:EntityAttributes> >> > </md:Extensions> >> > </md:EntityDescriptor> >> > >> > Thank you in advance for any help >> > Jakub >> > _______________________________________________ >> > satosa-users mailing list >> > satosa-users at lists.sunet.se >> > https://lists.sunet.se/listinfo/satosa-users >> >> >> >> -- >> Ivan c00kiemon5ter Kanakarakis >:3 >> >

3 years, 9 months

2
1
0 0

Specify remd:contactType and assert Sirtfi compliance in Satosa frontend metadata

by kuba.michal.n＠gmail.com

Hello, does anybody know how to specify remd:contactType for Satosa front-end? It is necessary for Refeds. Example: <md:ContactPerson contactType="other" remd:contactType=" http://refeds.org/metadata/contactType/security"> <md:Company>XYZ</md:Company> <md:GivenName>ABC</md:GivenName> <md:SurName>Security</md:SurName> <md:EmailAddress>mailto:security at example.com</md:EmailAddress> </md:ContactPerson> I would be also very thankful for help in adding this static string to metadata: <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ...> <md:Extensions> <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> </md:EntityDescriptor> Thank you in advance for any help Jakub

3 years, 9 months

2
1
0 0

Satosa not sending attributes to the SP

by kuba.michal.n＠gmail.com

Hello, It seems that Satosa is not sending attributes to the SP. The only exception is the one attribute specified in user_id_from_attrs. Is it a default behaviour? No SP specific policies were defined. [2021-08-11 15:57:36,463] [DEBUG] [satosa.backends.saml2._translate_response] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] backend received attributes: { "displayName": [ "plguser14" ], "eduPersonTargetedID": [ "64d759cc-1d21-4a29-a6e1-e7a10908d95e" ], "mail": [ "plguser14 at ops.pl" ], "sn": [ "czterna" ] } [2021-08-11 15:57:36,464] [DEBUG] [satosa.routing.frontend_routing] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] Routing to frontend: Saml2IDP-front [2021-08-11 15:57:36,464] [WARNING] [saml2.assertion.restrict] The metadata parameter for saml2.assertion.Policy.restrict is deprecated and ignored; instead, initialize the Policy object setting the mds param. [2021-08-11 15:57:36,465] [DEBUG] [saml2.assertion.filter] required: [{'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.25178.1.2.14', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrnam e-format:uri', 'friendly_name': 'schacPersonalUniqueCode', 'is_required': 'true'}], optional: [{'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10', 'name_format': 'urn:oasis :names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'eduPersonTargetedID'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', 'name_format': 'urn:oasis:names:tc:SAML :2.0:attrname-format:uri', 'friendly_name': 'eduPersonPrincipalName'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:0.9.2342.19200300.100.1.3', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrn ame-format:uri', 'friendly_name': 'mail'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:urn:oid:2.16.840.1.113730.3.1.241', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'fr iendly_name': 'displayName'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:2.5.4.3', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'cn'}, {'__class__': 'urn :oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'eduPersonScopedAffiliation'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.25178.1.2.9', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'schacHomeOrganization'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.13685.1.1.1.1.2.20', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'pleduOrgUniqueNumber'}] [2021-08-11 15:57:36,465] [DEBUG] [satosa.frontends.saml2._get_approved_attributes] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] Filter: ['edupersontargetedid', 'schacPersonalUniqueCode', 'mail'] [2021-08-11 15:57:36,465] [DEBUG] [satosa.attribute_mapping.from_internal] frontend attribute eduPersonTargetedID mapped from edupersontargetedid [2021-08-11 15:57:36,465] [DEBUG] [satosa.attribute_mapping.from_internal] frontend attribute email mapped from mail [2021-08-11 15:57:36,465] [DEBUG] [satosa.frontends.saml2._handle_authn_response] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] returning attributes {"eduPersonTargetedID": ["64d759cc-1d21-4a29-a6e1-e7a10908d95e"], "email": ["plguser14 at ops.pl"]} [2021-08-11 15:57:36,466] [DEBUG] [satosa.frontends.saml2._handle_authn_response] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2021-08-11 15:57:36,466] [DEBUG] [satosa.frontends.saml2._handle_authn_response] [urn:uuid:104101fc-b624-41d0-96d2-c952f11713f9] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256 [2021-08-11 15:57:36,466] [WARNING] [satosa.frontends.saml2._handle_authn_response] sign_alg and digest_alg are deprecated; instead, use signing_algorithm and digest_algorithm under the service/idp configuration path (not under policy/default). [2021-08-11 15:57:36,467] [DEBUG] [saml2.assertion.filter] required: [{'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.25178.1.2.14', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'schacPersonalUniqueCode', 'is_required': 'true'}], optional: [{'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'eduPersonTargetedID'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'eduPersonPrincipalName'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:0.9.2342.19200300.100.1.3', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'mail'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:urn:oid:2.16.840.1.113730.3.1.241', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'displayName'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:2.5.4.3', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'cn'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'eduPersonScopedAffiliation'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.25178.1.2.9', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'schacHomeOrganization'}, {'__class__': 'urn:oasis:names:tc:SAML:2.0:metadata&RequestedAttribute', 'name': 'urn:oid:1.3.6.1.4.1.13685.1.1.1.1.2.20', 'name_format': 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 'friendly_name': 'pleduOrgUniqueNumber'}] [2021-08-11 15:57:36,469] [INFO] [saml2.entity.sign] REQUEST: <ns0:Response xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2=" http://www.w3.org/2000/09/xmldsig#" Destination=" https://aai.pionier.net.pl/test/module.php/saml/sp/saml2-acs.php/default-sp" ID="id-HquE4vV74jkKMlK19" InResponseTo="_417162b56e4c88f4e2d89d05c295789a5d318a5d91" IssueInstant="2021-08-11T13:57:36Z" Version="2.0"><ns1:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> https://sso.pre.plgrid.pl:8081/Saml2IDP-front/proxy.xml</ns1:Issuer><ns2:Signature Id="Signature1"><ns2:SignedInfo><ns2:CanonicalizationMethod Algorithm=" http://www.w3.org/2001/10/xml-exc-c14n#" /><ns2:SignatureMethod Algorithm=" http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ns2:Reference URI="#id-HquE4vV74jkKMlK19"><ns2:Transforms><ns2:Transform Algorithm=" http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ns2:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ns2:Transforms><ns2:DigestMethod Algorithm=" http://www.w3.org/2001/04/xmlenc#sha256" /><ns2:DigestValue /></ns2:Reference></ns2:SignedInfo><ns2:SignatureValue /><ns2:KeyInfo><ns2:X509Data><ns2:X509Certificate>MIIFtzCCA5+gAwIBAgIJAMItW6x6FcDjMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNVBAYTAlBMMRYwFAYDVQQIDA1MZXNzZXIgUG9sYW5kMQ8wDQYDVQQHDAZDcmFjb3cxDDAKBgNVBAoMA0FDSzEQMA4GA1UECwwHQUNLLVNFQzEaMBgGA1UEAwwRc3NvLnByZS5wbGdyaWQucGwwHhcNMjEwNzMwMTIzODAxWhcNMjIwNzMwMTIzODAxWjByMQswCQYDVQQGEwJQTDEWMBQGA1UECAwNTGVzc2VyIFBvbGFuZDEPMA0GA1UEBwwGQ3JhY293MQwwCgYDVQQKDANBQ0sxEDAOBgNVBAsMB0FDSy1TRUMxGjAYBgNVBAMMEXNzby5wcmUucGxncmlkLnBsMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzwaBMIs/laH99rd6VxxIE/pbCv4oQqYelNRPEPpn9w+VmV5Er3RGfhGA8xuahHpFUu7rdqB0G96tmr7J8WMVCjEoDFnXkzYlJf8oul8BAsTXI2CnMw74mE98BnmT0/4jXIJbfcH9/UrtMVpR4pxIYV6CF2deXtPhFHxF8Sp+lhWCqEE27bxt7CVGoq5DMt9cm3qh6TtfdoLjALmKLjFvp6vBcyleufS1xv8AsXz0lHWJ6j8FdG2uBC75aZ9jWYZINopt90gJMUZpZ3XUfNm5DVFQqV3LyiNc4UNexqKtAydGtj6CWYXaBi5XiOflyINakSJf0v/3G5kFUonlleGsBgcq3xNU0ZeC+vjRoh4cA4CpIcvq//VvQvG9jcL5ExUhNc5niMuCBMNiJzPXG0l+HewX+n0PRG/XiYBlgC8dhYmaZXqyHpja5y4UjvKXlJxqcPxdqxfzoe30jK4UlgQZ2hu0i1pOQ+TdVURISJYKu2AjI9WmQ6J0F/77yaSez2J4MkqjZWADEv7EG/fdvCrCl/rSMNX6cEbHZHu8wu+OpWX15tF6av+CKt43NyPTFdB+vC2bHNSFzDAZwYwyX14HkNwkWHjerrGQSK9VdqoOBb2/NRGlHffpvyoS7Jd7TFD8Po26936rfF4weS/Urd9KLrOrg+dpU/8DT7jlROBNDtMCAwEAAaNQME4wHQYDVR0OBBYEFHqQWjL3v2VO2GjeRt221qP/Kkz7MB8GA1UdIwQYMBaAFHqQWjL3v2VO2GjeRt221qP/Kkz7MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggIBAK7m+DKYQsyzniRNCWm4bgeqJ4fBjEdjw6xn8kB43MRTlaOQ41wMB7Qu2MM1umJida3/tIySbHGph/l/l3I/SanlUOAS9ahiKJtWUOj03XDdAKkQPf1ij7NqAq7Ealw9NVee+vhew36hD6m/jskjcJJEmbufb08QgeX7G7dG1jkSr2rfXhGzOnXIvAGiqizkRrI7WUNxferqU6CLgn1LxH3oSQa747dKPG02w0flphSN6f81+H2vxsIddvkeC1NSUq92sIfiMuYuKnzNkEheiFJ6JQpCaHH1yYJpkd8xoMZrSAosNprBYxMyS8cwEColCCdkiUcpab1xE4f3TF12O4eWEKSZw0MxH/FdPUvOjE9IMuGhQOMxbMQFw9AJnY2PNRHotMmyZQ5xUCUjUvfeE5FkD/rM1U8GWDSxoDPx9ORMebU3w2oXR8r4PUc//n405fXn/s4IYA3SleoaU5XmDtfg1QVd/4rN5rCa4yMqIzhVpZli6umVOYULbzhxAnpCd0PwUGoGfPniKg7fNHB5veSRzLXju8JaW7ldJacvkXnWzAnh3ti0BJQ29DbTUZ/QsjWGhzMfub31jp8lPK+tuphTkWoGok0sZRhKLH+2Sdkcb+jJkbhv0Ft197vnMZvz4Ybn4suAP5/GE2ZCgKDj7J9OJ37n/KyiD3gUKJasWFDk</ns2:X509Certificate></ns2:X509Data></ns2:KeyInfo></ns2:Signature><ns0:Status><ns0:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></ns0:Status><ns1:Assertion ID="id-X2qR3due6dcurArXi" IssueInstant="2021-08-11T13:57:36Z" Version="2.0"><ns1:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> https://sso.pre.plgrid.pl:8081/Saml2IDP-front/proxy.xml</ns1:Issuer><ns1:Subject><ns1:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">64d759cc-1d21-4a29-a6e1-e7a10908d95e</ns1:NameID><ns1:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><ns1:SubjectConfirmationData InResponseTo="_417162b56e4c88f4e2d89d05c295789a5d318a5d91" NotOnOrAfter="2021-08-11T14:12:36Z" Recipient=" https://aai.pionier.net.pl/test/module.php/saml/sp/saml2-acs.php/default-sp" /></ns1:SubjectConfirmation></ns1:Subject><ns1:Conditions NotBefore="2021-08-11T13:57:36Z" NotOnOrAfter="2021-08-11T14:12:36Z"><ns1:AudienceRestriction><ns1:Audience> https://aai.pionier.net.pl/test/module.php/saml/sp/metadata.php/default-sp</ns1:Audience></ns1:AudienceRestriction></ns1:Conditions><ns1:AuthnStatement AuthnInstant="2021-08-11T13:57:36Z" SessionIndex="id-YX0liwOPeyOoMqBv7"><ns1:AuthnContext><ns1:AuthnContextClassRef>default-LoA</ns1:AuthnContextClassRef><ns1:AuthenticatingAuthority> https://sso.pre.plgrid.pl/auth/realms/PLGRID</ns1:AuthenticatingAuthority></ns1:AuthnContext></ns1:AuthnStatement><ns1:AttributeStatement><ns1:Attribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns1:AttributeValue><ns1:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">64d759cc-1d21-4a29-a6e1-e7a10908d95e</ns1:NameID></ns1:AttributeValue></ns1:Attribute></ns1:AttributeStatement></ns1:Assertion></ns0:Response> [2021-08-11 15:57:36,472] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command: /bin/xmlsec1 --sign --privkey-pem /etc/satosa/plugins/frontends/frontend.key --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:Response --node-id id-HquE4vV74jkKMlK19 --output /tmp/tmp3ylf1dxd.xml /tmp/tmpj9ip14kl.xml [2021-08-11 15:57:36,516] [INFO] [saml2.entity.apply_binding] HTTP POST Logs from SP: Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] <ns1:AttributeStatement> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] <ns1:Attribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] <ns1:AttributeValue> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] <ns1:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">64d759cc-1d21-4a29-a6e1-e7a10908d95e</ns1:NameID> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] </ns1:AttributeValue> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] </ns1:Attribute> Aug 11 11:34:20 simplesamlphp DEBUG [ed6e68a42d] </ns1:AttributeStatement> Thank you in advance for any help! Jakub

3 years, 10 months

2
7
0 0

KeyError when routing to frontend

by ymniezab＠cyfronet.krakow.pl

Hello, We are trying to use Satosa as proxy for Keycloak. After successful login backend receives attributes and tries to route them to frontend named Saml2IDP (same name as in the example) but fails: [2021-08-05 11:03:50,412] [DEBUG] [satosa.attribute_mapping.to_internal] backend attribute ['sn', 'surname'] mapped to surname [2021-08-05 11:03:50,413] [DEBUG] [satosa.backends.saml2._translate_response] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] backend received attributes: { "sn": [ "czterna" ] } [2021-08-05 11:03:50,413] [DEBUG] [satosa.routing.frontend_routing] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Routing to frontend: Saml2IDP [2021-08-05 11:03:50,413] [ERROR] [satosa.base.run] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Uncaught exception Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' [2021-08-05 11:03:50,416] [ERROR] [satosa.proxy_server.__call__] Unknown error Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/proxy_server.py", line 118, in __call__ resp = self.run(context) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 258, in run raise SATOSAUnknownError("Unknown error") from err satosa.exception.SATOSAUnknownError: Unknown error Thank you in advance for any help!

3 years, 10 months

2
1
0 0

KeyError when routing to frontend

by kuba.michal.n＠gmail.com

Hello, We are trying to use Satosa as proxy for Keycloak. After successful login backend receives attributes and tries to route them to frontend named Saml2IDP (same name as in the example) but fails: [2021-08-05 11:03:50,412] [DEBUG] [satosa.attribute_mapping.to_internal] backend attribute ['sn', 'surname'] mapped to surname [2021-08-05 11:03:50,413] [DEBUG] [satosa.backends.saml2._translate_response] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] backend received attributes: { "sn": [ "czterna" ] } [2021-08-05 11:03:50,413] [DEBUG] [satosa.routing.frontend_routing] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Routing to frontend: Saml2IDP [2021-08-05 11:03:50,413] [ERROR] [satosa.base.run] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Uncaught exception Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' [2021-08-05 11:03:50,416] [ERROR] [satosa.proxy_server.__call__] Unknown error Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/proxy_server.py", line 118, in __call__ resp = self.run(context) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 258, in run raise SATOSAUnknownError("Unknown error") from err satosa.exception.SATOSAUnknownError: Unknown error Thank you in advance for any help!

3 years, 10 months

2
5
0 0

KeyError when routing to frontend

by ymniezab＠cyfronet.krakow.pl

Hello, We are trying to use Satosa as proxy for Keycloak. After successful login backend receives attributes and tries to route them to frontend named Saml2IDP (same name as in the example) but fails: [2021-08-05 11:03:50,412] [DEBUG] [satosa.attribute_mapping.to_internal] backend attribute ['sn', 'surname'] mapped to surname [2021-08-05 11:03:50,413] [DEBUG] [satosa.backends.saml2._translate_response] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] backend received attributes: { "sn": [ "czterna" ] } [2021-08-05 11:03:50,413] [DEBUG] [satosa.routing.frontend_routing] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Routing to frontend: Saml2IDP [2021-08-05 11:03:50,413] [ERROR] [satosa.base.run] [urn:uuid:6e039cb0-5454-4224-987e-1965c623cad9] Uncaught exception Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' [2021-08-05 11:03:50,416] [ERROR] [satosa.proxy_server.__call__] Unknown error Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 240, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 180, in _run_bound_endpoint return spec(context) File "/usr/local/lib/python3.6/site-packages/satosa/backends/saml2.py", line 350, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 149, in _auth_resp_callback_func context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 120, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 86, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 317, in _handle_authn_response request_state = self.load_state(context.state) File "/usr/local/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 149, in load_state state_data = state[self.name] File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__ raise KeyError(key) KeyError: 'Saml2IDP' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/proxy_server.py", line 118, in __call__ resp = self.run(context) File "/usr/local/lib/python3.6/site-packages/satosa/base.py", line 258, in run raise SATOSAUnknownError("Unknown error") from err satosa.exception.SATOSAUnknownError: Unknown error Thank you in advance for any help!

3 years, 10 months

1
0
0 0

OIDC frontend introspection endpoint

by thijs.kinkhorst＠surf.nl

Hi all, I've set up Satosa as a proxy between a SAML 2.0 backend and an OpenID Connect frontend (OP). This works fine for the basic flow, but the RP indicates they're missing the introspect endpoint. I was looking though the docs but could not find information about support for it. Am I overlooking something or does Satosa not support introspection? Kind regards, Thijs Kinkhorst SURF

4 years, 1 month

3
2
0 0

Exposing SAML 2.0 IdP Entity ID in OIDC Frontend

by christian.franke＠picturepipe.com

Hello, we've been setting up SATOSA as a proxy that uses the SAML 2.0 backend to authenticate against a SAML federation, and provides authentication via the OpenID Connect frontend. We've successfully managed to map attributes from the SAML side to scopes on the OIDC side. However, to qualify these attributes, it seems sensible to also check the SAML entity ID of the IdP that made the assertions. How can we expose the entity ID of the IdP asserting the identity of the user on the OIDC side? All Best, Chris -- Christian Franke reelport GmbH Karl-Heine-Str. 93 04229 Leipzig Germany Email: christian.franke at picturepipe.com GPG-KeyID: 0xB657CF42AE512BEE Phone: +49-157-34575984 Web: http://www.picturepipe.com/ CEO Tilman Scheel Amtsgericht Duisburg, HRB 17622 USt-IdNr.: DE814323473

4 years, 3 months

2
3
0 0

Satosa-Saml2Saml example project

by giuseppe.demarco＠unical.it

Hello everyone, I have pulled up an example project which exemplifies a SATOSA saml2saml proxy demo. Specifically, I use my pySAML2 and SATOSA forks for interoperability with SPID (Italian Digital Identity System) but all this is not necessary for those who do not have the same problems I have! I share as it is, here https://github.com/peppelinux/Satosa-Saml2Spid probably the only convincing innovation for those who already deal with SATOSA, excluding the animated gif in the readme (!), is that my Dockerfile adopts alpine linux, consuming less than half the storage space normally required by Debian and overall I also register a performance gain, but I haven't certain numbers at the moment, only "Human sensations" :') best regards Giuseppe ____________________ Giuseppe De Marco Centro ICT d'Ateneo Università della Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it

4 years, 4 months

1
0
0 0

setting up a saml2-to-oidc proxy

by chris.mailing＠gmx.net

Hello, I'm currently trying to setup SATOSA as a proxy with a SAML2 backend and an OIDC frontend as I have a few apps that only support OIDC connect, but not SAML. Following the doc https://github.com/IdentityPython/SATOSA/blob/master/doc/saml2-to-oidc.md I created the necessary config files, but I can't make much sense out of the configuration parameters as https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#proxy_co… only describes a few of them and only on a very high level. Most importantly: - are <base_url> and <name> actual (auto-populated?) variables or do I have to replace them? base_url may be obvious (BASE from proxy_conf.yaml?) but what is "name"? - am I really supposed to generate the metadata manually using https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#saml_met… or is that achieved automatically by "entityid_endpoint: true" already? if not where does the resulting file need to be put an referenced? - with "entityid_endpoint: true" and "entityid: '<base_url>/<name>/metadata'" configured shouldn't I be able to download the SP metadata from this very URL? This doesn't seem to work for me (but may be related to Q1) as I'm only getting "The Service or Identity Provider you requested could not be found." (with various variations of name being "app" or "sp") - which backend endpoints are actually needed for a simple saml2-to-oidc use case? Reading through the mailing list I have only seen some known issues when connecting to Shibboleth as IdP. Are there also known issues or recommended configuration parameters when connecting to a SimpleSAMLphp IdP? Thanks for any pointers! Chris

4 years, 4 months

2
1
0 0

Potential issue w/ deleted subject-identifiers from MongoDB in v7.x

by david.huebner＠daasi.de

Hi folks, this topic probably needs further investigation. I'll share my findings and welcome any ideas on how to further debug this. Maybe someone else has encountered the same problem? We're using Satosa as the basis for various of our deployments. This issue occurs in any v7 version of Satosa and is not limited to only the most recent 7.0.3. The pySAML2 security vulnerability only was the trigger for me to finally upgrade from 6.1.0 which we have been using until now. This upgrade also includes raising the pyop dependency from 3.0.1 to 3.1.0 for what it's worth. I removed as much of our custom config and code as possible, notably switching back to the vanilla OIDC frontend without any modifications. Basically, MongoDB entries for subject-identifier are being deleted whenever another access token is generated (i.e. another user logs in). This leads to all previous access tokens being unusable for accessing userinfo etc.: [Wed Jan 27 13:00:49 2021] [wsgi] [ERROR] [satosa.base] [/usr/local/lib/python3.6/site-packages/satosa/base.py - line 257]: [urn:uuid:652c74dc-bab6-46a4-8be8-d83fa215a281] Uncaught exception ... [Wed Jan 27 13:00:49 2021] [wsgi] File "/usr/local/lib/python3.6/site-packages/pyop/authz_state.py", line 315, in get_user_id_for_subject_identifier [Wed Jan 27 13:00:49 2021] [wsgi] raise InvalidSubjectIdentifier('{} unknown'.format(subject_identifier)) [Wed Jan 27 13:00:49 2021] [wsgi] pyop.exceptions.InvalidSubjectIdentifier: 00000000-0000-0000-0000-000000000002 unknown Consider the following example: 1) Login with Account 1 (sub=00000000-0000-0000-0000-000000000002) 2) Login with Account 2 in another browser (sub=ddd3a947-b5e1-4f59-a757-eab8231aa687) With 6.1.0 MongoDB would now look like this: { _id: ObjectId('60115fab8486770baffef551'), lookup_key: 'superadmin', data: { 'public': '00000000-0000-0000-0000-000000000002' }, modified_ts: 1611751339.31406 } { _id: ObjectId('60115fe08486770baffef5f5'), lookup_key: 'a at b.de', data: { 'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687' }, modified_ts: 1611751392.2613952 } With 7.x MongoDB contains *only* the following entry instead: { _id: ObjectId('60115fe08486770baffef5f5'), lookup_key: 'a at b.de', data: { 'public': 'ddd3a947-b5e1-4f59-a757-eab8231aa687' }, modified_ts: 1611751392.2613952 } If that makes any difference, we're only using public sub claims: fe_id: openid: [sub] which are generated from LDAP attributes: search_return_attributes: didmosUUID: fe_id I have not yet tested with pairwise claims. Any ideas are much appreciated :) Cheers, David -- David Hübner, Solutions Engineer DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: david.huebner at daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz

4 years, 4 months

1
0
0 0

SaToSa throughput problems

by JonathanANewell＠hotmail.com

Hello SaToSa list! We are experiencing unexpected poor performance with SaToSa. (1K requests/minute) . We are seeing very high resource use with XMLSEC binary (default option) and using pyXMLSecurity (crypto_backend configuration) with encryption disabled. Here is our setup: Load Balancer=>EC2=>NGINX=>Gunicorn. (NGINX=>Gunicorn is on the UDS, not network stack) EC2 instance size information: (OS is AWS linux) Model vCPU Memory (GiB) Instance Storage (GiB) Network Bandwidth (Gbps) EBS Bandwidth (Mbps) c5n.2xlarge 8 21 EBS-Only Up to 25 Up to 4,750 Gunicorn is set to the "thread" model: import multiprocessing workers = multiprocessing.cpu_count() * 2 + 1 threads = multiprocessing.cpu_count() * 2 + 1 We have 8 core boxes. Any suggestion on things we may try ? TIA -Jonathan

4 years, 5 months

3
2
0 0

Vulnerabilities affecting pySAML2 and forthcoming release

by ivan.kanak＠gmail.com

Dear users of IdentityPython, this is a heads-up about two vulnerabilities affecting pySAML2. Software that uses pySAML2 is indirectly affected, too (ie, SATOSA). The issues were reported to the IdentityPython incident-response mailing list and we have been working on a mitigation. A new version of pySAML2 that includes the fixes will be released on Wednesday 20th of January between 13:00 CET and 17:00 CET. We urge everyone to be prepared to update their setup to the latest version. Kind regards, Ivan Kanakarakis on behalf of the incident-response team

4 years, 5 months

1
3
0 0

Backend not responding (SAML-to-SAML)

by c.nattero＠fadeout.it

satosa-users at lists.sunet.se Hi all, we're trying to set up a proxy SAML-SAML between our service provider (keycloak) and an IdP federation, following this guide <https://github.com/IdentityPython/SATOSA/blob/master/doc/one-to-many.md> (and a variant <https://github.com/daserzw/satosa-oidc-to-saml>). It looks like the backend side is unreachable or, at least, the metadata are: if we HTTP GET <base_url>/<name>/proxy_saml2_backend.xml (as specified in the backend yaml config file) the server replies: 404 The Service or Identity Provider you requested could not be found. Whereas if we try to HTTP GET the frontend, we can retrieve the corresponding xml. Any ideas why this is happening and how to fix it, or how to further investigate it? Thanks for your support. Cristiano -- Cristiano Nattero, PhD FadeOut Software srl http://fadeout.it/ -- Privacy - Reg. UE 679/2016 (GDPR) - Questo messaggio, ed ogni eventuale allegato, è riservato e confidenziale e indirizzato esclusivamente ai destinatari indicati. La segretezza della corrispondenza elettronica è tutelata dalle leggi in vigore, pertanto l’intercettazione, la lettura o la riproduzione di questo messaggio da parte di persone a cui non è destinato, è espressamente vietata. Privacy - Reg. UE 679/2016 (GDPR) - This message, with any attachments, is intended only for use of the individual or entity to which it is addressed and contains confidential information that may also be privileged. Secrecy of electronic mail is protected by law in force. If you are not the intended recipient of this message, you are hereby notified that interception, distribution or copying of this communication is strictly prohibited.

4 years, 5 months

2
2
0 0

I'd like to know when the micro service works. (satosa-oidc-to-saml)

by j2mity＠gmail.com

Dear. satosa-developers Recently, I studying OpenID Connect and SAML using Satosa (oidc-to-saml) I have a question. I'd like to know 1. satosa-oidc-to-saml flow that includes micro_service 2. when the micro_services works when I set up the micro service. 3. Can I add new attributes to OIDC Provider without hard coding and mapping them between oidc and saml attributes? (oidc-to-saml) Could you tell me the answer to the above and about Satosa?

4 years, 8 months

1
0
0 0

I have a question about operations in satosa.

by j2mity＠gmail.com

Hello I'm having a strange error with my Satosa (oidc-to-saml) frontend [satosa.frontends.openid_connect]: invalid client authentication at token endpoint Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/satosa/frontends/openid_connect.py", line 362, in token_endpoint response = self.provider.handle_token_request(urlencode(context.request), headers) File "/usr/local/lib/python3.6/site-packages/pyop/provider.py", line 319, in handle_token_request token_request = self._verify_client_authentication(request_body, http_headers) File "/usr/local/lib/python3.6/site-packages/pyop/provider.py", line 425, in _verify_client_authentication token_request['client_id'] = verify_client_authentication(self.clients, token_request, http_headers.get('Authorization')) File "/usr/local/lib/python3.6/site-packages/pyop/client_authentication.py", line 57, in verify_client_authentication raise InvalidClientAuthentication(client_secret) pyop.exceptions.InvalidClientAuthentication: None The above error repeats over and over again. I'm not sure if it's problem with client_id registration, tokenEndpoint, or Satosa internal settings. Could you tell me how to solve this problem?

4 years, 8 months

2
1
0 0

Attributes removed from response incorrectly

by hannah.short08＠gmail.com

Hello, (Apologies, cross posting from Slack) I’m having a strange error with my Satosa frontend that seems to be stripping out attributes incorrectly from the SAML response before it is sent, based on required attributes from SP metadata. It receives the correct values from an upstream IdP: returning attributes {"eduPersonUniqueId": ["... at cern.ch"], "displayName": ["Hannah Short"], "givenName": ["Hannah"], "mail": ["hannah.short at cern.ch"], "cn": ["Hannah Short"], "sn": ["Short"], "eduPersonScopedAffiliation": [" member at cern.ch"], "eduPersonAffiliation": ["member"], "eduPersonPrincipalName": ["hshort at cern.ch"], "eduPersonAssurance": [" https://refeds.org/assurance/ID/unique", " https://refeds.org/assurance/ATP/ePA-1m", " https://refeds.org/assurance/IAP/low"], "schacHomeOrganization": ["cern.ch"], "schacHomeOrganizationType": ["urn:schac:homeOrganizationType:ch:others"], "swissEduPersonHomeOrganization": ["cern.ch"], "swissEduPersonHomeOrganizationType": ["others"], "swissEduPersonUniqueID": ["... at cern.ch"], "eduPersonTargetedID": ["..."]} However, it then checks the “required” attributes from the target SP and decides to strip out the swiss* ones (despite them being required in the SP’s metadata and I can also see that they are required in the debug statement). My swiss* attributes are defined in an attribute map, and I’m running satosa 6.0.0. I’m really stuck here, I just rolled out this IdP and will have to roll back if I can’t fix this quickly :( Can I ignore “required” attributes as a workaround? When none are required the token gets sent as expected Thanks in advance for any help, Hannah

4 years, 9 months

1
1
0 0

SAMLVirtualCoFrontend metadata

by Ulrik.Ahlander＠Xlent.Se

Hi I´m trying to setup SAMLVirtualCoFrontend with three entityIDs, but got a problem that I hope someone knows about. It seems as all three entityIDs are get up by SATOSA as I can see this in the log: Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/post Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/post' Created URL regex (^Saml2)/(Org1|Org2|Org3)/sso/redirect Adding mapping ('(^Saml2)/(Org1|Org2|Org3)/sso/redirect' But the metadata frontend.xml only contains entityID for the last entry, in this case "Org3". The log shows that metadata is written three times to the same file, see log entry below. Writing metadata to '/cfg/metadata/frontend.xml' Writing metadata to '/cfg/metadata/frontend.xml' Writing metadata to '/cfg/metadata/frontend.xml' Writing metadata to '/cfg/metadata/backend.xml' Is there anything I can do to get correct frontend metadata for all three COs ? A configuration item to get separate filenames or something? I´m using latest Docker image satosa/satosa as of yesterday /Ulrik Å

4 years, 10 months

3
5
0 0

SAMLFrontend versus SAMLVirtualCOFrontEnd

by JonathanANewell＠hotmail.com

Hello SatoSa list! This is my first post as I am just getting started with SatoSa. Thanks to all for making it possible. I love it so far, the code and semantics are very clean! Question: It seems that I can configure SAMLFrontend and SAMLVirtualCoFrontend to both operate correctly in my topology ( 1 or many SP => 1 IdP. OR 1 SP=> many IdP ) as such I am uncertain of which module would be best to use. Can someone in the community tell me why I would want to use one module over the other? I think I must be missing some functional capabilities afforded by one but not the other. TIA -Jonathan +++

4 years, 10 months

3
2
0 0

custom attribute

by janusz.ulanowski＠heanet.ie

Hi, I'm having few issues and hopefully you might provide some light saml to saml scenario. I wanted to add custom attribute: I added that attribute to saml_uri.py 'fro': { 'urn:mace:heanet.ie:custom:tenantid': 'customtenantid', ... }, 'to': { 'customtenantid': 'urn:mace:heanet.ie:custom:tenantid', ... } then internal_attributes.yaml : added: customtenantid: saml: [customtenantid, urn:mace:heanet.ie:custom:tenantid] in saml2_frontend.yaml policy is set to allow release everything: policy: default: attribute_restrictions: null however: logs say: /////////////// xx | [2020-07-20 20:59:47,604] [DEBUG] [satosa.frontends.saml2._get_approved_attributes] [urn:uuid:244a93be-a61e-4e5f-8508-c293a24f832d] Filter: ['name', 'schacHomeOrganization', 'edupersontargetedid', 'givenname', 'eppn', 'organizationName', 'mail', 'displayname', 'surname'] ////////////// where does that filter come from if I have set not restriction . Is it only way to add a custom atribute ? thanks in advance, Janusz

4 years, 11 months

3
4
0 0

SAMLBackend: Unknown error

by janusz.ulanowski＠heanet.ie

Hi, I hope you might give some light. I'm trying to setup saml2saml. Everything works fine when samlBackend gets metadata with only one IdP. When there is more then I'm getting error. backends/saml2_backend.yaml is based saml2_backend.yaml.example I would be very much appreciated for any help. ############################ jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [DEBUG] [satosa.routing.backend_routing] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Routing to backend: Saml2 jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,978] [INFO] [satosa.backends.saml2.get_idp_entity_id] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] {'message': 'Selected IdP', 'only_one': False, 'target_entity_id': None, 'force_authn': None, 'memorized_idp': False, 'entity_id': None} agger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,979] [ERROR] [satosa.base.run] [urn:uuid:4391da61-03e6-44c3-b706-2f31694b9b33] Uncaught exception jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last): jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url: jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable jagger_satosa.1.niwh0x0v4r34 at totoro | [2020-06-18 14:44:26,980] [ERROR] [satosa.proxy_server.__call__] Unknown error jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last): jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 240, in run jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self._run_bound_endpoint(context, spec) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 180, in _run_bound_endpoint jagger_satosa.1.niwh0x0v4r34 at totoro | return spec(context) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 100, in handle_authn_request jagger_satosa.1.niwh0x0v4r34 at totoro | return self._handle_authn_request(context, binding_in, self.idp) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/frontends/saml2.py", line 256, in _handle_authn_request jagger_satosa.1.niwh0x0v4r34 at totoro | return self.auth_req_callback_func(context, internal_req) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 103, in _auth_req_callback_func jagger_satosa.1.niwh0x0v4r34 at totoro | return self._auth_req_finish(context, internal_request) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 108, in _auth_req_finish jagger_satosa.1.niwh0x0v4r34 at totoro | return backend.start_auth(context, internal_request) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 179, in start_auth jagger_satosa.1.niwh0x0v4r34 at totoro | return self.disco_query(context) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/backends/saml2.py", line 211, in disco_query jagger_satosa.1.niwh0x0v4r34 at totoro | disco_url, self.sp.config.entityid, **args jagger_satosa.1.niwh0x0v4r34 at totoro | File "/opt/satosa/lib/python3.7/site-packages/saml2/client_base.py", line 936, in create_discovery_service_request jagger_satosa.1.niwh0x0v4r34 at totoro | if '?' in url: jagger_satosa.1.niwh0x0v4r34 at totoro | TypeError: argument of type 'NoneType' is not iterable jagger_satosa.1.niwh0x0v4r34 at totoro | jagger_satosa.1.niwh0x0v4r34 at totoro | The above exception was the direct cause of the following exception: jagger_satosa.1.niwh0x0v4r34 at totoro | jagger_satosa.1.niwh0x0v4r34 at totoro | Traceback (most recent call last): jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/proxy_server.py", line 118, in __call__ jagger_satosa.1.niwh0x0v4r34 at totoro | resp = self.run(context) jagger_satosa.1.niwh0x0v4r34 at totoro | File "/src/satosa/src/satosa/base.py", line 258, in run jagger_satosa.1.niwh0x0v4r34 at totoro | raise SATOSAUnknownError("Unknown error") from err jagger_satosa.1.niwh0x0v4r34 at totoro | satosa.exception.SATOSAUnknownError: Unknown error ############################

5 years

2
2
0 0

Help with SaToSa

by kristo.jorgenson＠gmail.com

Hi all, I am a developer working on an open source project called SimplyE which is an eBook platform originally developed by the New York Public Library, but now being used by many public libraries across the US. The company I work for (Lyrasis) is currently adding support for university libraries, and with that comes supporting SAML. We are looking for someone experienced in federated authentication to assist us in this, and I thought I would reach out here to see if anyone is looking for contract work. If you are interested, or know anyone who might be, please be in touch with me via this email. Thanks so much, Kristo

5 years, 2 months

1
0
0 0

InvalidAuthorizationCode

by peter.schober＠univie.ac.at

Since I've been able to answer my own question about manual client registration (w/o MongoDB) in another thread (now resolved) https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html I'm starting a new thread about the latter (unrelated) issue: Starting at the oidc-enabled app I'm sent to satosa with an auth request, the client is now known/found (client_db details shared at the above URL), the saml backend is involked, SAML WebSSO happens, attributes are mapped and I am back "Routing to frontend: oidc". Then satosa raises an InvalidAuthorizationCode exception: [pyop.authz_state.create_authorization_code] creating authz code for scope=openid email profile [pyop.authz_state.create_authorization_code] new authz_code=eff...cd79 to client_id=someClientId for sub=someid at example.org valid_until=1585612419 ... [satosa.proxy_server.unpack_request] read request data: {'grant_type': 'authorization_code', 'code': 'eff...cd79', 'redirect_uri': 'https://some.example.org/auth/callback'} ... [pyop.client_authentication.verify_client_authentication] client authentication in Authorization header Basic base64-encoded-client_id_colon_client_secret [satosa.frontends.openid_connect.token_endpoint] invalid request: eff...cd79 unknown Traceback (most recent call last): File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/frontends/openid_connect.py", line 363, in token_endpoint response = self.provider.handle_token_request(urlencode(context.request), headers) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py", line 324, in handle_token_request return self._do_code_exchange(token_request, extra_id_token_claims) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py", line 352, in _do_code_exchange authentication_request = self.authz_state.get_authorization_request_for_code(token_request['code']) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/authz_state.py", line 320, in get_authorization_request_for_code raise InvalidAuthorizationCode('{} unknown'.format(authorization_code)) pyop.exceptions.InvalidAuthorizationCode: eff...cd79 unknown So the authz code created above (first line) is now unkown (last line). Why would that happen and what can I do to avoid it? On the RP side (seemingly using https://www.npmjs.com/package/openid-client) I currently only see the same thing as RP is merely relaying the OP error, it seems. And this being an OP error I probably don't have to dig into the RP side to get more/better logging: OPError: invalid_grant (eff...cd79 unknown) at processResponse (/opt/edumeet/mm/server/node_modules/openid-client/lib/helpers/process_response.js:45:13) at Client.grant (/opt/edumeet/mm/server/node_modules/openid-client/lib/client.js:1235:26) at process._tickCallback (internal/process/next_tick.js:68:7) I'd appreciate suggestions on what I could have done wrong following the satosa documentation where available, or how to further debug this issue. If other/more information (config details, logs, etc.) are needed or my obscuring of details above is unclear I'm happy to provide those. -peter

5 years, 2 months

2
2
0 0

"Unknown error" when testing SAML2 backend

by peter.schober＠univie.ac.at

Hej, I'm looking at an application (eduMEET, a custom frontend for mediasoup, AFAICT) that comes with OIDC support but needs to be made available to our SAML federation members, of course. satosa seems to be a common choice for this (though I wouldn't be unhappy if I could avoid protocol translation, e.g. by proxying from httpd+mod_shib). I'm going with the current (6.1.0) satosa release from the cheeseshop. Ignoring my failed attempts to deploy this in uwsgi for now, I start the application and everything seems to be going well (using Gunicorn plus HTTP proxying and TLS-offloading): * I've configured the SAML backend including a remote metadata url and cert and the logs indicate the metadata is being consumed. * I've "configured" (guessed at a few things) but not yet used the OIDC frontend. * No microservices as of yet. [2020-03-26 11:43:13 +0000] [7135] [INFO] Starting gunicorn 20.0.4 [2020-03-26 11:43:13 +0000] [7135] [INFO] Listening at: http://127.0.0.1:8080 (7135) [2020-03-26 11:43:13 +0000] [7135] [INFO] Using worker: sync [2020-03-26 11:43:13 +0000] [7138] [INFO] Booting worker with pid: 7138 [2020-03-26 11:43:13,860] [INFO] [satosa.base.__init__] Loading backend modules... [2020-03-26 11:43:13,936] [DEBUG] [saml2.httpbase.send] GET to https://eduid.at/md/aconet-registered.xml [2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.send] Response status: 200 [2020-03-26 11:43:14,003] [DEBUG] [saml2.httpbase.set_cookie] eduid.at: 'Set-Cookie: ...' [2020-03-26 11:43:14,606] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command: /usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem aconet-metadata-signing.crt --id-attr:ID urn:oasis:names:tc:SAML:2.0:metadata:EntitiesDescriptor --output /tmp/tmp9gt_vrc6.xml /tmp/tmpmhnh96n3.xml [2020-03-26 11:43:14,681] [INFO] [satosa.plugin_loader.load_backends] Setup backends: ['saml'] [2020-03-26 11:43:14,681] [INFO] [satosa.base.__init__] Loading frontend modules... [2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_frontends] Setup frontends: ['oidc'] [2020-03-26 11:43:14,804] [INFO] [satosa.base.__init__] Loading micro services... [2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_request_microservices] Loaded request micro services: [] [2020-03-26 11:43:14,804] [INFO] [satosa.plugin_loader.load_response_microservices] Loaded response micro services:[] [2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded backends with endpoints: [<satosa.backends.saml2.SAMLBackend object at 0x7f45e59ad0b8>] [2020-03-26 11:43:14,805] [DEBUG] [satosa.routing.__init__] Loaded frontends with endpoints: [<satosa.frontends.openid_connect.OpenIDConnectFrontend object at 0x7f45e54d3b70>] [2020-03-26 11:43:14,806] [DEBUG] [satosa.routing.__init__] Loaded micro services with endpoints: [] So far so good. I've also used `satosa-saml-metadata` to generate backend.xml. That contained a copy of the provided SAML SP certificate, though with a use="signing" restriction. (I.e., the metadata generated that way would fail with any default Shibboleth IDP. Unless pysaml2 doesn't support encrypted assertions or reponses I consider this a bug. At least neither the satosa nor the pysaml2 docs had anything on this.) So I've removed that 'use' restriction to cause the IDP to send encrypted assertions but later also /disabled/ that in the IDP again: I get the same exception either way, so this may not in fact be related. With no idea how to test the SAML side of things (I know nothing about OIDC and so left the OP setup and RP integration for later) I sent the SP an unsolilcited response from my IDP. ('allow_unsolicited: True' is set in the SAML backend config) which ultimately fails with an "Unknown error". Stdout from Gunicorn below: [2020-03-26 11:43:41,080] [DEBUG] [satosa.proxy_server.unpack_post] unpack_post:: {'SAMLResponse': ... [2020-03-26 11:43:41,081] [DEBUG] [satosa.proxy_server.unpack_request] read request data: {'SAMLResponse': ... [2020-03-26 11:43:41,081] [INFO] [satosa.base._load_state] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Loaded state {'SESSION_ID': 'urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59'} from cookie [2020-03-26 11:43:41,081] [DEBUG] [satosa.routing.endpoint_routing] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Routing path: saml/acs/post [2020-03-26 11:43:41,082] [DEBUG] [satosa.routing._find_registered_endpoint_for_module] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Found registered endpoint: module name:'saml', endpoint: saml/acs/post [2020-03-26 11:43:41,083] [DEBUG] [saml2.response._loads] xmlstr: ... [2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._check_signature] ==== Certs from metadata ==== https://idp.example.edu/saml: [<tempfile._TemporaryFileWrapper object at 0x7f45e67d67b8>, <tempfile._TemporaryFileWrapper object at 0x7f45e67d67f0>] ==== [2020-03-26 11:43:41,086] [DEBUG] [saml2.sigver._run_xmlsec] xmlsec command: /usr/bin/xmlsec1 --verify --enabled-reference-uris empty,same-doc --pubkey-cert-pem /tmp/tmpqaj6buom.pem --id-attr:ID urn:oasis:names:tc:SAML:2.0:protocol:Response --node-id _b2ea47f03f30638517a9649f8baf4e1f --output /tmp/tmphc_hm0cw.xml /tmp/tmp8mavdoev.xml [2020-03-26 11:43:41,098] [DEBUG] [saml2.response._postamble] response: ... [2020-03-26 11:43:41,103] [DEBUG] [saml2.entity._parse_response] XMLSTR: b'...' [2020-03-26 11:43:41,103] [INFO] [saml2.response.status_ok] status: <ns0:Status xmlns:ns0="urn:oasis:names:tc:SAML:2.0:protocol"><ns0:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></ns0:Status> [2020-03-26 11:43:41,104] [DEBUG] [saml2.response.parse_assertion] ***Encrypted assertion/-s*** [2020-03-26 11:43:41,105] [DEBUG] [saml2.response.parse_assertion] --- AVA: {} [2020-03-26 11:43:41,105] [ERROR] [satosa.base.run] [urn:uuid:b370f69a-d7e2-49b6-9e32-e31920b89d59] Uncaught exception Traceback (most recent call last): File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 289, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 229, in _run_bound_endpoint return spec(context) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py", line 341, in authn_response if context.state[self.name]["relay_state"] != context.request["RelayState"]: File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line 1025, in __getitem__ raise KeyError(key) KeyError: 'saml' [2020-03-26 11:43:41,106] [ERROR] [satosa.proxy_server.__call__] Unknown error Traceback (most recent call last): File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 289, in run resp = self._run_bound_endpoint(context, spec) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 229, in _run_bound_endpoint return spec(context) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/backends/saml2.py", line 341, in authn_response if context.state[self.name]["relay_state"] != context.request["RelayState"]: File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py", line 1025, in __getitem__ raise KeyError(key) KeyError: 'saml' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/proxy_server.py", line 117, in __call__ resp = self.run(context) File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/base.py", line 307, in run raise SATOSAUnknownError("Unknown error") from err satosa.exception.SATOSAUnknownError: Unknown error Now, the KeyError comes from the 'name' of my SAML backend plugin config: module: satosa.backends.saml2.SAMLBackend name: saml So when context.state[self.name] doesn't exist (or doesn't have a "relay_state" key itself) in authn_response() from satosa/backends/saml2.py I guess something about the relaystate of COOKIE_STATE_NAME or my deployment could be off? Here's that part from my proxy_conf.yaml (I haven't checked the code yet what the defaults are, the documentation doesn't mention any): BASE: https://test.example.edu COOKIE_STATE_NAME: satosa_state # Also tried with delete set to False CONTEXT_STATE_DELETE: True STATE_ENCRYPTION_KEY: somestring cookies_samesite_compat: - [satosa_state, "SATOSA_STATE_LEGACY"] Another data point: When trying to start SAML SSO by accessing the discovery_response endpoint at <base>/<name>/disco I end up with the exception raised in disco_response() from satosa/backends/saml2.py ("No IDP chosen for state" / "No IDP chosen") Any pointers? Should I post (even) more config snippets? Logs from the other exception too, when accessing the disco endpoint? Cheers, -peter

5 years, 2 months

2
13
0 0

oidc client registration

by peter.schober＠univie.ac.at

Not knowing whether my satosa instance is fully working yet (see my other thread) I'm now continuing to try to get the application (eduMEET) to work with satosa's oidc frontend, as per the app's published config example: https://github.com/havfo/multiparty-meeting/blob/master/server/config/confi… So I've made up a client_id and client_secret on the RP side and provided the client with an issuerURL (base URL of satosa), let it request all the scopes in the world and set its own redirect_uri. With those all set I do see requests to satosa's .well-known endpoints from the application in satosa logs, e.g. Found registered endpoint: module name:'oidc', endpoint: .well-known/openid-configuration (And of course accessing the endpoint myself I can see that it works and produces JSON with its config.) Now on the OP side (satosa oidc frontend) I haven't done any setup for the client yet, so I guess the error in the log is to be expected: Error in authn req: Unknown client_id Now what would be the next steps to register that client? The request from the client (according to satosa's logs) has these query parameters (where cid and csec are the correct client_id and client_secret, respectively): client_id=cid&scope=openid+email+profile&response_type=code&redirect_uri=https%3A%2F%2Fexample.org%2Fauth%2Fcallback&state=e30%3D&client_secret=csec My plugins/frontends/openid_connect_frontend.yaml looks like the published example, essentially: module: satosa.frontends.openid_connect.OpenIDConnectFrontend name: oidc config: signing_key_path: /etc/satosa/oidc-provider.key #db_uri: mongodb://db.example.com # optional: only support MongoDB, will default to in-memory storage if not specified client_db_path: /etc/satosa/oidc-clients.json provider: client_registration_supported: True response_types_supported: ['code', 'token', 'id_token'] subject_types_supported: ['public', 'pairwise'] scopes_supported: ['openid', 'email', 'profile'] Only that I tried to enable pretty much everything (all repose and subject types, all scopes, client registration) since I had no idea what the RP side wants, yet. (Seems I can remove all response types except 'code', as per the log shown above.) I don't have MongoDB set up yet since the comment above suggests an in-memory store would be used, which is fine for my current testing. And looking at _create_provider() at frontends/openid_connect.py the code would use the file referenced by client_db_path if db_uri isn't set even before falling back to storing it in a variable. The file referenced in client_db_path exists, is writable by the user satosa runs as, and currently contains only '{}' (without the quotes). So IMO that should be sufficient. Any hints on how to register the application? The documenation is a bit sparse here https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#frontend… only mentioning that *without* dynamic client registration (which I have enabled for now, but maybe the RP doesn't support it) I'd have to manually create the data structures in MongoDB (or the file in client_db_path) for my client, as per the oidc spec for Client Registration Responses. Could someone share a json sample to put into the file referenced by client_db_path (if that's how it's supposed to work)? Cheers, -peter

5 years, 2 months

1
1
0 0

SATOSA Single Logout Service

by ferdy.mul＠ncr.nstda.or.th

Hi SATOSA users, Currently, we are working on SSO project which is Zoom SSO service. We use SATOSA proxy in order to connect with our identity federation (one-to-many type), and we have already implemented single sign-on (SSO) service and it's working, however we still require single logout service (SLO). We couldn't find any SATOSA configuration regarding to SLO from SATOSA documentation. Without SLO, although user has already selected and clicked log out from Zoom, the session still there, otherwise user requires to clear the browser cache. Could you explain to us, how to implement SLO in SATOSA? Thank you. ---------------- Best regards, Mr. Ferdy Mulyadi Research Assistant Internet Innovation Research Team (INO - CNWRG) National Electronics and Computer Technology Center (NECTEC) National Science and Technology Department Agency (NSTDA) Thailand Science Park (TSP) - 112 Phaholyothin Rd., Khlong Nueng, Khlong Luang Pathum Thani, THAILAND ________________________________ Disclaimer: This e-mail and any files transmitted with it may contain confidential and proprietary information of the National Science and Technology Development Agency (NSTDA), Thailand. They are intended solely for the use of the addressed individuals or entities. If you are not the intended recipient, you are required to immediately delete this e-mail and its contents from your system. Any disclosure, distribution, or action based upon the contents of this e-mail is strictly prohibited. Any views or opinions presented in this e-mail are solely those of the sender and do not necessarily represent those of NSTDA. NSTDA does not accept any responsibility for the content of this message or the consequences of any actions taken on the basis of the information provided. NSTDA accepts no liability for any damage caused by any virus or malware which may be inserted in this e-mail during transmission.

5 years, 4 months

2
1
0 0

FW: SATOSA Single Logout Service

by ferdy.mul＠ncr.nstda.or.th

Resend. From: Ferdy Mulyadi <ferdy.mul at ncr.nstda.or.th> Sent: Selasa, 04 Februari 2020 10.15 To: 'satosa-users at lists.sunet.se' <satosa-users at lists.sunet.se> Subject: SATOSA Single Logout Service Hi SATOSA users, Currently, we are working on SSO project which is Zoom SSO service. We use SATOSA proxy in order to connect with our identity federation (one-to-many type), and we have already implemented single sign-on (SSO) service and it's working, however we still require single logout service (SLO). We couldn't find any SATOSA configuration regarding to SLO from SATOSA documentation. Without SLO, although user has already selected and clicked log out from Zoom, the session still there, otherwise user requires to clear the browser cache. Could you explain to us, how to implement SLO in SATOSA? Thank you. ---------------- Best regards, Mr. Ferdy Mulyadi Research Assistant Internet Innovation Research Team (INO - CNWRG) National Electronics and Computer Technology Center (NECTEC) National Science and Technology Department Agency (NSTDA) Thailand Science Park (TSP) - 112 Phaholyothin Rd., Khlong Nueng, Khlong Luang Pathum Thani, THAILAND ________________________________ Disclaimer: This e-mail and any files transmitted with it may contain confidential and proprietary information of the National Science and Technology Development Agency (NSTDA), Thailand. They are intended solely for the use of the addressed individuals or entities. If you are not the intended recipient, you are required to immediately delete this e-mail and its contents from your system. Any disclosure, distribution, or action based upon the contents of this e-mail is strictly prohibited. Any views or opinions presented in this e-mail are solely those of the sender and do not necessarily represent those of NSTDA. NSTDA does not accept any responsibility for the content of this message or the consequences of any actions taken on the basis of the information provided. NSTDA accepts no liability for any damage caused by any virus or malware which may be inserted in this e-mail during transmission.

5 years, 4 months

2
1
0 0

SATOSA only_use_keys_in_metadata flag

by dirk.daems＠vito.be

Hi, we are using SATOSA to allow EduGAIN users to access our services. The service is protected by KeyCloak and in KeyCloak we configured SATOSA as a SAML Identity Provider. Users from the EduGAIN access-check IdP can now access the service, but it looks like we have problems with some IdP's which don't have a signing key in the EduGAIN metadata. When looking in file '/opt/satosa/lib/python3.5/site-packages/saml2/sigver.py' there is a flag 'only_use_keys_in_metadata' which looks to be set to True, which means that only signing keys from the metadata files are allowed. When I hardcode this flag to be set to False, also users from IdP's without a signing key can authenticate, but I can't seem to find where I can configure this in the SATOSA saml2_backend.yaml file. Is it possible to configure this flag in SATOSA? Thanks, Dirk Indien u VITO Mol bezoekt, hou aub er dan rekening mee dat de hoofdingang voortaan enkel bereikbaar is vanuit de richting Dessel-Retie, niet vanuit richting Mol, zie vito.be/route.<http://www.vito.be/route> If you plan to visit VITO at Mol, then please note that the main entrance can only be reached coming from Dessel-Retie and no longer coming from Mol, see vito.be/en/contact/locations.<http://www.vito.be/en/contact/locations> VITO Disclaimer: http://www.vito.be/e-maildisclaimer

5 years, 6 months

2
1
0 0

Question regarding double WAYF prompt

by jblok＠beeldengeluid.nl

Hi all, Our SP application connects to an identity federation via Satosa. We have two authentication flows, one which starts the authentication process using SAML and one which starts the authentication flow using OIDC. The entire process works well when using OIDC only, however, a requirement is that we can start the same process via SAML. After authentication (via SAML) is completed, the SP application tries to - Request a code - Request an OIDC access token using the code - Check the access token using the userinfo endpoint The issue that we are facing in the flow which starts the authentication by SAML, is that the user is presented with the WAYF page twice. The first time during the SAML flow, and the second time when requesting an OIDC code. I assumed that because the user had just authenticated themselves, Satosa would be able to return a code without asking the user to authenticate again. My questions are: - Have I made a mistake in assuming this is a logical process to use for authentication and authorisation? Is using SAML and OIDC in a mixed way a bad idea? - Is it possible to receive a OIDC code or access token as a result of a SAML authentication flow? - If not, is it possible to receive a code or access token without asking the user to authenticate once again? I would imagine setting Satosa to 'remember IdP' would forgo the second round of authentication when using SAML. Are there other options of achieving this? Thank you in advance. Kind regards, Jonathan Blok -- Kind regards, *Jonathan Blok* Technical Project Officer / Software Developer *T* +31 35 - 677 16 79 | *M* +31 6 - 4 669 14 58 *Availability:* Mon, Tue, Wed, Fri <http://www.beeldengeluid.nl/> *Netherlands Institute for Sound and Vision | Nederlands Instituut voor Beeld en Geluid* *Media Parkboulevard 1, 1217 WE Hilversum | Postbus 1060, 1200 BB Hilversum | * *beeldengeluid.nl* <http://www.beeldengeluid.nl/> <http://files.beeldengeluid.nl/handtekening/index.html>

5 years, 9 months

1
0
0 0

MFA and SATOSA

by jaj＠virginia.edu

I will have some SPs behind the proxy that need to use the refeds MFA profile via InCommon along with other SPs behind the same proxy that only require simple one-step password authentication. I’ve looked through the list archives and don’t see a solution to the problem I’m having. I can verify by watching the browser saml flow that the SP is correctly requesting refeds mfa in RequestedAuthnContext. However, this request does not appear to be passed on to the selected IdP and the MFA authentication attribute is not set upon return. There appears to be configuration available (acr_mapping) to specify what AuthnContextClassRef value satosa returns to the SP based on the selected IdP but that is not what we need for this application. My question: is satosa supposed to pass the SP’s requested AuthnContext to the end user’s IdP and pass back the IdP’s response? I’ll dig some more but am hoping that someone already knows how/if this should work in satosa. Thanks much, Jim

5 years, 9 months

2
3
0 0

Adding to attribute maps

by hannah.short＠cern.ch

Hi Satosa users, I’m trying to add the Swiss eduPerson attributes [1] to the Satosa attribute maps [2] but running into problems when trying to use them. I’m running Satosa with Docker and have pulled the swiss attributes into .py files in the attributemaps folder, added them to my internal_attribute.yaml schema, restarted my container… however they don’t seem to be recognised. ========================== The attribute coming from my IdP ========================== <ns0:Attribute FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute> ==================================================== The config in internal_attribute.yaml (I just want to pass the attribute straight through to my Eps) ==================================================== swissedupersonhomeorganization: saml: [swissEduPersonHomeOrganization] ========================== Debug messages ========================== "Unknown attribute name: <ns0:Attribute xmlns:ns0="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" FriendlyName="swissEduPersonHomeOrganization" Name="urn:oid:2.16.756.1.2.5.1.1.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><ns0:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">cern.ch</ns0:AttributeValue></ns0:Attribute>” ... "skipped backend attribute '['swissEduPersonHomeOrganization']': no value found” The OID appears to be correct (SWISSEDUPERSON_OID = 'urn:oid:2.16.756.1.2.5.1.1.’, SWISSEDUPERSON_OID+’4' =‘swissEduPersonHomeOrganization’). Am I missing something? Some missing config or some cache somewhere? Thanks in advance for any advice, Hannah [1] https://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf [2] https://github.com/IdentityPython/SATOSA/pull/270

5 years, 10 months

3
8
0 0

pyMultiLDAP as SATOSA microservice

by giuseppe.demarco＠unical.it

Hi to everybody, I'm doing fine with pyMultiLDAP as MS [3]. I can test multiple LDAP connections with received, aggregated and rewritten data directly with pymultildap from command line, before move configuration to deployed systems. The same settings[1] used command line would be used in MS configuration, as is. I'm using multildap in satosa, in my pysaml2 Idp[2] and also as general purpose LDAP proxy for SEARCH and BIND methods, with the help of slapd-sock. At this moment I do not need too much parameters per SP in the MS configuration but probably in the future I will. I preferred to delegate data behaviour directly in multildap.settings instead of MS configuration. I share as it come, regards [1] https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.… <https://github.com/peppelinux/pyMultiLDAP/blob/master/examples/settings.py.…> [2] https://uniauth.readthedocs.io/en/latest/index.html [3] https://github.com/peppelinux/pyMultiLDAP/tree/fe602e39240d6a3240f09c852cb6… -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it

5 years, 10 months

1
0
0 0

<resolved>Re: Guidance sought on allowing attributes to pass through with statosa/statosa:latest

by Chris.Phillips＠canarie.ca

Hi. I believe I have resolved my issues and have a functioning SATOSA instance in my pre-prod environment. I hit 5 main items (so far) and hope that capturing can help others have an easier story. I’m interested in helping improve docs and need guidance as to where and how – github wiki? Fork repo then do a pull request? Reflections on using SATOSA in pre-prod use marching toward full production use so far: * Starting from zero to this stage was non-small but any other proxy story would have been more effort IMO. * These items were costly in time to come by and hope that it helps shorten implementations to capture them. * If I had them, SATOSA is a slam dunk on fastest and ‘thinnest’ deployment. Kudos to the work put into SATOSA and for future work on the horizon. Thoughts and questions welcome as always .. my notes and details on how I resolved things are below. C Main challenges and steps taken to have SATOSA operating as expected for attribute passing and assertion handling ======================================================= 1. Sp.xml proved impactful on parsing if it had too much in it thus rendering the filter attributes empty =========== I had ACS entries for required/requested attributes which seem to have bumped my internal_attributes filter sufficiently to zero (empirical observation) My resolution: remove those elements as well as the MD contact info from the sp.xml metadata appeared to have resolved this first step Suggestion: more clarity on this element would help. 1. YAML syntax on how to ingest an aggregate in the ‘backend’ was tough to decipher and documentation is thin or maybe aged out. =========== My resulting format working for my docker image: satosa/satosa:latest for the backend.yaml is: <snip> metadata: remote: - {url: "https://url.to/fed.xml", cert: "/opt/satosa/etc/pki/testfed.crt"} <snip> This does not align with documentation that I’ve encountered for SATOSA. Suggestion: configuration for multi-lateral federation would benefit to be an example. As would version sensitivity of it and more examples to show what would be sufficient to run 1. Internal_attributes.yaml mapping transformed email to mail thus downstream was ‘no email, no access!’ =========== The mapping of email to mail OIDs – YIKES! Who knew that PKCS_9 +1 vs UCL_DIR_PILOT+3 were different? I hated myself on this one * The hurt was in internal_attributes.yaml had * Mail: * Saml: [email, emailAddress, mail] * As such it translated the Shib assertion from ‘mail’ to ‘email’ OID Action taken to resolve: set saml: [mail] for the mail element Suggestion: there’s a lot to talk about here on mapping – this is a place for some good practices and what’s there looks good for just working but the transposition was subtle to detect. Hard to say how to make it easier without more thought. 1. Run SATOSA behind apache to trap errors better was tough to find and used a slightly different way than the WSGI interface =========== The reference to error handling is a bit oblique as there’s more than one way to do it and the WSGI apache proxy was not immediately there for me Here’s the snippet from the apache2 config that allows me to handle the 404’ing of access for a more graceful error page handling: # # proxy SATOSA so we can handle 404's better # don’t forget to a2en proxy; a2en proxy_http in apache2 # ProxyErrorOverride is **CRITICAL** to trap the 404 passed up by gunicorn. Proxypass /Saml2 http://127.0.0.1:8000/Saml2 ProxyPassReverse /Saml2 http://127.0.0.1:8000/Saml2 ProxyErrorOverride On ErrorDocument 404 /errors/404.html Suggestion: This is a strong need for error handling. Templating it for the enhancement listed in the issue tracker not so much as just give me some plain html locations to use or mount in the container rather than punting to a proxy above resulting in a proxy of a proxy. 1. To handle ADFS assertions inbound to SATOSA properly needed the backend.yaml/federation facing settings to want_response_signed=False and not ‘true’ =========== Testing various IdPs like Shibboleth and ADFS revealed that to use ADFS out of the box with a SAML trust to SATOSA I needed want_response_signed=False. * This deploys as ‘true’ for SATOSA recommended (and is a good posture to be fair!) but ADFS won’t play fair with it that I could tell. * This was only uncovered while reading ‘Signature error: Signature missing for respose’ in google and found this: * https://github.com/IdentityPython/pysaml2/issues/490 Suggestion: Again, this is a practitioner configuration. Thankfully the setting is there, now it needs more revelation in documentation and how to use things and consequences of the action like this. From: Chris Phillips <Chris.Phillips at canarie.ca> Date: Friday, July 19, 2019 at 8:50 AM To: "satosa-users at lists.sunet.se" <satosa-users at lists.sunet.se> Subject: Guidance sought on allowing attributes to pass through with statosa/statosa:latest Hi. I’m trying to work through a SATOSA story of SP with only one IdP configured to be proxied to use a federation aggregates’ metadata. Sign on is working and always get Filter: [] and returning attributes {} when I expect attributes to be sent by SATOSA. I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in YAML 😊 I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker and a v3.4.8 install: https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html I have seen/explored the microservices/ filter_attributes.yaml.example but that is more along suppression rather than permit passage. Must I whitelist everything? Thanks for any insight/guidance on this. I have a gist with front/backends here: https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559 Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or the edugain.slack.com location have idpy like venues for chats like this? C satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint: module name:'Saml2', endpoint: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email', 'emailAdress', 'mail']' mapped to mail satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['postaladdress']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn', 'surname']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['displayName']' mapped to displayname satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['givenName']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['eduPersonTargetedID']' mapped to edupersontargetedid satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['cn']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes: satosa_1 | { satosa_1 | "eduPersonPrincipalName": [ satosa_1 | "something at canarie.ca" satosa_1 | ], satosa_1 | "mail": [ satosa_1 | "Chris.Phillips at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonScopedAffiliation": [ satosa_1 | "staff at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonAffiliation": [ satosa_1 | "staff" satosa_1 | ], satosa_1 | "eduPersonTargetedID": [ satosa_1 | "SUPPRESED=" satosa_1 | ], satosa_1 | "displayName": [ satosa_1 | "Chris Phillips" satosa_1 | ] satosa_1 | } satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend: Saml2IDP satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Filter: [] satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {} satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie, secure: True, max-age: 1200, path: /

5 years, 10 months

3
2
0 0

Production deployments of Satosa?

by jbanning＠oreilly.com

Hello satosa users, O'Reilly Media is working to build out a proper multilateral federation SP for our platform. We have deployed Shibboleth SP3 for development but are finding that integrating our existing systems with Shib to be inefficient and rather kludgy. SATOSA looks like a great fit for our python-based AuthN/Z OIDC backend but I have only identified a handful of deployments (E.G. GÉANT and possibly CERN). We would use it as a SAML backend and OIDC frontend with InCommon's MDQ feed and, initially, their discovery service as well. For those who have deployed SATOSA in production, what has your experience been in terms of reliability and maintainability, either generally or as compared to Shib SP3? Also, can you share roughly how much ongoing IT and development time has been needed to maintain a high level of uptime? I welcome additional feedback and suggestions as well. Thank you! -jesse -- Jesse Banning Manager of Platform Integration O'Reilly Media, Inc. <https://oreilly.com> (Boston Office <https://www.google.com/maps/place/O'Reilly>) (617)499-7575 | jbanning at oreilly.com Calendar: https://beta.doodle.com/jbanning

5 years, 10 months

2
1
0 0

Guidance sought on allowing attributes to pass through with statosa/statosa:latest

by Chris.Phillips＠canarie.ca

Hi. I’m trying to work through a SATOSA story of SP with only one IdP configured to be proxied to use a federation aggregates’ metadata. Sign on is working and always get Filter: [] and returning attributes {} when I expect attributes to be sent by SATOSA. I’m using the docker image Latest and have also tried v4.4.0 with same result. I don’t think I’m too fancy and am using SATOSA ‘out of the box’ and am looking for guidance/insight/suggestions on what may be wrong, missing, or off by a few columns in YAML 😊 I have had success in the past at TIIME in Feb2019 with Matt E. but that was non-docker and a v3.4.8 install: https://lists.sunet.se/pipermail/satosa-users/2019-February/000067.html I have seen/explored the microservices/ filter_attributes.yaml.example but that is more along suppression rather than permit passage. Must I whitelist everything? Thanks for any insight/guidance on this. I have a gist with front/backends here: https://gist.github.com/canariecaf/2216d3de5e5872ecaa08cf03548ec559 Happy to jump on Slack and chat there too – is there a slack area for satosa/idpy BTW or the edugain.slack.com location have idpy like venues for chats like this? C satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing path: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Found registered endpoint: module name:'Saml2', endpoint: Saml2/acs/post satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['email', 'emailAdress', 'mail']' mapped to mail satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['postaladdress']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['sn', 'surname']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['displayName']' mapped to displayname satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['givenName']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: backend attribute '['eduPersonTargetedID']' mapped to edupersontargetedid satosa_1 | [2019-07-19 02:21:07] [DEBUG]: skipped backend attribute '['cn']': no value found satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] backend received attributes: satosa_1 | { satosa_1 | "eduPersonPrincipalName": [ satosa_1 | "something at canarie.ca" satosa_1 | ], satosa_1 | "mail": [ satosa_1 | "Chris.Phillips at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonScopedAffiliation": [ satosa_1 | "staff at canarie.ca" satosa_1 | ], satosa_1 | "eduPersonAffiliation": [ satosa_1 | "staff" satosa_1 | ], satosa_1 | "eduPersonTargetedID": [ satosa_1 | "SUPPRESED=" satosa_1 | ], satosa_1 | "displayName": [ satosa_1 | "Chris Phillips" satosa_1 | ] satosa_1 | } satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Routing to frontend: Saml2IDP satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Filter: [] satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] returning attributes {} satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] signing with algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] using digest algorithm http://www.w3.org/2001/04/xmlenc#sha256 satosa_1 | [2019-07-19 02:21:07] [DEBUG]: [urn:uuid:d7919f3e-0361-4ec5-aa1b-b5560eb6305c] Saving state as cookie, secure: True, max-age: 1200, path: /

5 years, 11 months

1
0
0 0

binding a microservice to either a frontend or backend

by rainer＠hoerbe.at

Is there an option to limit a microservice to either frontend or backend? If not, I would propose to extend MicroService with 2 bool args, like: def __init__(self, name, base_url, backend=True, frontend=True, **kwargs): Thanks, Rainer

6 years, 1 month

3
4
0 0

ResponseMicroService reading information in Request

by Alex.Stuart＠jisc.ac.uk

Dear Satosa Users, I'm trying to create a ResponseMicroService which generates a subject identifier of pairwise-id [1] from the eduPersonTargetedID provided by the Home Organization's IdP. To avoid collisions, I want the input to the generator for the pairwise-id to contain entityID + '!' + eduPersonTargetedID, but the Response Context doesn't appear to contain the entityID of the originating IdP. Evidently I don't understand the model which SATOSA uses to pass information from backend to frontend... - Is there a way to access the proxied IdP's entityID from a ResponseMicroService? - Would it be better to generate the attribute in a RequestMicroService? - Do microservices act in the order that they're defined in proxy_conf.yaml? For example, can I define a microservice to generate the new attribute from an existing attribute, and then filter out the existing attribute. Any information appreciated. Thanks, Alex [1] SAML subject identifier attributes, https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-su… — Alex Stuart Principal technical support specialist (UK federation) alex.stuart at jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

6 years, 2 months

2
1
0 0

SAML-Frontend complains about rsa-sha256 algorithm

by rainer＠hoerbe.at

Using a SAMl2SAML configuration I get 'Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' <http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'>. pysaml2 does support his since a couple of years. Has anybody encountered this? - Rainer [2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Routing to frontend: Saml2IDP [2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Filter: ['name', 'telephoneNumber', 'surname', 'givenname', 'mail', 'uid', 'displayname', 'title'] [2019-04-09 21:01:44] [DEBUG]: frontend attribute displayName mapped from displayname [2019-04-09 21:01:44] [DEBUG]: frontend attribute givenName mapped from givenname [2019-04-09 21:01:44] [DEBUG]: frontend attribute email mapped from mail [2019-04-09 21:01:44] [DEBUG]: frontend attribute cn mapped from name [2019-04-09 21:01:44] [DEBUG]: frontend attribute sn mapped from surname [2019-04-09 21:01:44] [DEBUG]: frontend attribute uid mapped from uid [2019-04-09 21:01:44] [DEBUG]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] returning attributes {"displayName": ["User Test"], "givenName": ["Test"], "email": ["test at bmspot.gv.at"], "cn": ["Test User"], "sn": ["User"], "uid": ["test at bmspot.gv.at"]} [2019-04-09 21:01:44] [ERROR]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2019-04-09 21:01:44] [ERROR]: [urn:uuid:0afc6b35-2ff2-436e-a7db-bb8d2fc877a0] Uncaught exception Traceback (most recent call last): File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 366, in _handle_authn_response args['sign_alg'] = getattr(xmldsig, sign_alg) AttributeError: module 'saml2.xmldsig' has no attribute 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 286, in run resp = self._run_bound_endpoint(context, spec) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 228, in _run_bound_endpoint return spec(context) File "/opt/venv/lib/python3.6/site-packages/satosa/backends/saml2.py", line 238, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 197, in _auth_resp_callback_func context, internal_response) File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 168, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 84, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 370, in _handle_authn_response raise Exception(errmsg) from e Exception: Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2019-04-09 21:01:44] [ERROR]: Unknown error Traceback (most recent call last): File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 366, in _handle_authn_response args['sign_alg'] = getattr(xmldsig, sign_alg) AttributeError: module 'saml2.xmldsig' has no attribute 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 286, in run resp = self._run_bound_endpoint(context, spec) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 228, in _run_bound_endpoint return spec(context) File "/opt/venv/lib/python3.6/site-packages/satosa/backends/saml2.py", line 238, in authn_response return self.auth_callback_func(context, self._translate_response(authn_response, context.state)) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 197, in _auth_resp_callback_func context, internal_response) File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/attribute_modifications.py", line 17, in process return super().process(context, data) File "/opt/venv/lib/python3.6/site-packages/satosa/micro_services/base.py", line 33, in process return self.next(context, data) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 168, in _auth_resp_finish return frontend.handle_authn_response(context, internal_response) File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 84, in handle_authn_response return self._handle_authn_response(context, internal_response, self.idp) File "/opt/venv/lib/python3.6/site-packages/satosa/frontends/saml2.py", line 370, in _handle_authn_response raise Exception(errmsg) from e Exception: Unsupported sign algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/opt/venv/lib/python3.6/site-packages/satosa/proxy_server.py", line 113, in __call__ resp = self.run(context) File "/opt/venv/lib/python3.6/site-packages/satosa/base.py", line 302, in run raise SATOSAUnknownError("Unknown error") from err satosa.exception.SATOSAUnknownError: Unknown error

6 years, 2 months

1
1
0 0

Satosa and Rocket.Chat problem

by thomas.bellembois＠uca.fr

Hello, I have difficulties configuring Satosa in front of my Rocket.Chat serveur to provide Shibboleth authentication. I have open an issue on the Github with my configuration files. I am properly redirected to the WAYF but after the authentication I have an error. UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfd in position 0: invalid start byte I can not figure out where I am wrong. Could you help me ? Regards, Thomas -- Thomas BellemboisAdministrateur système - IUT/DSI (UCA)Université Clermont Auvergne5 avenue Blaise Pascal - CS 3008663178 Aubière Cedex04.73.17.71.23

6 years, 3 months

1
0
0 0

SATOSA Quickstart

by xenophon＠irtnog.org

I want to again say "thanks" to Ioannis, Rainer, Scott, and everyone else for their help and instruction during the various IdentityPython and SATOSA meetings at TIIME this week. Chris Phillips and I were able to get a SATOSA 3.4.8 deployment working in Chris's idp-installer test bed. To that end I want to share my notes from the process, at the end of which an interested party could perform a basic, end-to-end test of the current SATOSA release using SAMLtest (https://samltest.id/) 1. I installed Ubuntu Server 18.04.1; run the following commands as root to install the prerequisites: ```sh apt update apt dist-upgrade -y apt install -y git python3-dev build-essential python3-pip libffi-dev libssl-dev xmlsec1 libyaml-dev libxml2-utils pip3 install --upgrade virtualenv virtualenv -p python3 /opt/satosa /opt/satosa/bin/pip install --upgrade pip setuptools /opt/satosa/bin/pip install SATOSA ``` This is essentially the Docker image build process, only it uses the current SATOSA release (etc.) on PyPI. 2. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/docker/attributemap s to /opt/satosa/attributemaps. I'm not sure this is strictly necessary as the built-in pysaml2 attribute maps should be used by default, but it's what the Docker image build process does. 3. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/example to /opt/satosa/etc. 4. SATOSA doesn't have a default configuration, so you must provide it yourself. ```sh cp /opt/satosa/etc/proxy_conf.yaml.example \ /opt/satosa/etc/proxy_conf.yaml cp /opt/satosa/etc/internal_attributes.yaml.example \ /opt/satosa/etc/internal_attributes.yaml cp /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml.example \ /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml cp /opt/satosa/etc/plugins/backends/saml2_backend.yaml.example \ /opt/satosa/etc/plugins/backends/saml2_backend.yaml cp /opt/satosa/etc/plugins/microservices/static_attributes.yaml.example \ /opt/satosa/etc/plugins/microservices/static_attributes.yaml ``` 5. You may change the proxy URL (the value of BASE in /opt/satosa/etc/proxy_conf.yaml), but it _must_ be a method plus hostname without any trailing slash or path components, e.g., `https://proxy.example.com`, not `https://proxy.example.com/` nor `https://proxy.example.com/satosa`. SATOSA must be hosted at the root of your web site. 6. Comment out the `idp_blacklist_file` and `disco_srv` settings in /opt/satosa/etc/plugins/backends/saml2_backend.yaml. 7. Generate IdP, SP, metadata signing, and web site keying material: ```sh for i in frontend backend metadata https; do openssl req -batch -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /opt/satosa/etc/$i.key -out /opt/satosa/etc/$i.crt \ -subj /CN=proxy.example.com done ``` 8. Download the SAMLtest metadata. ```sh curl https://samltest.id/saml/sp > /opt/satosa/etc/sp.xml curl https://samltest.id/saml/idp > /opt/satosa/etc/idp.xml ``` 9. Generate the proxy metadata. (How you do this changes in future releases of SATOSA.) ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc satosa-saml-metadata proxy_conf.yaml metadata.key metadata.crt --split-frontend --split-backend --dir /opt/satosa/etc xmllint --format /opt/satosa/etc/Saml2IDP_0.xml > /opt/satosa/etc/proxy-idp.xml xmllint --format /opt/satosa/etc/Saml2_0.xml > /opt/satosa/etc/proxy-sp.xml ``` 10. Edit the proxy metadata files to remove the `<ns1:Signature>` element, else SAMLtest will be unable to load them due to an invalid signature. 11. Upload the proxy metadata to SAMLtest (https://samltest.id/upload.php) 12. SAMLtest doesn't release the eduPerson Targeted ID attribute, so you'll need to change the last three lines of /opt/satosa/etc/internal_attributes.yaml to the following (and before anyone says anything, NEVER USE AN EMAIL ADDRESS AS AN IDENTIFIER---this is just a quick hack to get SATOSA working): ``` hash: [mail] user_id_from_attrs: [mail] user_id_to_attr: mail ``` 13. Start SATOSA: ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc gunicorn -b0.0.0.0:443 --keyfile https.key --certfile https.crt satosa.wsgi:app ``` 14. At this point you should be able to perform an IdP test (https://samltest.id/start-idp-test/) by specifying the entity ID of the proxy's front end, e.g., https://example.com/Saml2IDP/proxy.xml. The SAMLtest SP will request authentication by your proxy IdP, causing your proxy SP to request authentication by the SAMLtest IdP. If everything works right, you will end up back at the SAMLtest SP: SAMLtest SP ---AuthnRequest---> SATOSA front end (IdP)/back end (SP) ---AuthnRequest---> SAMLtest IdP SAMLtest SP <---AuthnResponse--- SATOSA front end (IdP)/back end (SP) <---AuthnResponse--- SAMLtest IdP I hope this helps other adopters. If you have any questions, please reply on list so everyone can benefit from the discussion. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

6 years, 4 months

2
1
0 0

SATOSA Quickstart

by xenophon＠irtnog.org

I want to again say "thanks" to Ioannis, Rainer, Scott, and everyone else for their help and instruction during the various IdentityPython and SATOSA meetings at TIIME this week. Chris Phillips and I were able to get a SATOSA 3.4.8 deployment working in Chris's idp-installer test bed. To that end I want to share my notes from the process, at the end of which an interested party could perform a basic, end-to-end test of the current SATOSA release using SAMLtest (https://samltest.id/) 1. I installed Ubuntu Server 18.04.1; run the following commands as root to install the prerequisites: ```sh apt update apt dist-upgrade -y apt install -y git python3-dev build-essential python3-pip libffi-dev libssl-dev xmlsec1 libyaml-dev libxml2-utils pip3 install --upgrade virtualenv virtualenv -p python3 /opt/satosa /opt/satosa/bin/pip install --upgrade pip setuptools /opt/satosa/bin/pip install SATOSA ``` This is essentially the Docker image build process, only it uses the current SATOSA release (etc.) on PyPI. 2. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/docker/attributemap s to /opt/satosa/attributemaps. I'm not sure this is strictly necessary as the built-in pysaml2 attribute maps should be used by default, but it's what the Docker image build process does. 3. Copy https://github.com/IdentityPython/SATOSA/tree/v3.4.8/example to /opt/satosa/etc. 4. SATOSA doesn't have a default configuration, so you must provide it yourself. ```sh cp /opt/satosa/etc/proxy_conf.yaml.example \ /opt/satosa/etc/proxy_conf.yaml cp /opt/satosa/etc/internal_attributes.yaml.example \ /opt/satosa/etc/internal_attributes.yaml cp /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml.example \ /opt/satosa/etc/plugins/frontends/saml2_frontend.yaml cp /opt/satosa/etc/plugins/backends/saml2_backend.yaml.example \ /opt/satosa/etc/plugins/backends/saml2_backend.yaml cp /opt/satosa/etc/plugins/microservices/static_attributes.yaml.example \ /opt/satosa/etc/plugins/microservices/static_attributes.yaml ``` 5. You may change the proxy URL (the value of BASE in /opt/satosa/etc/proxy_conf.yaml), but it _must_ be a method plus hostname without any trailing slash or path components, e.g., `https://proxy.example.com`, not `https://proxy.example.com/` nor `https://proxy.example.com/satosa`. SATOSA must be hosted at the root of your web site. 6. Comment out the `idp_blacklist_file` and `disco_srv` settings in /opt/satosa/etc/plugins/backends/saml2_backend.yaml. 7. Generate IdP, SP, metadata signing, and web site keying material: ```sh for i in frontend backend metadata https; do openssl req -batch -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /opt/satosa/etc/$i.key -out /opt/satosa/etc/$i.crt \ -subj /CN=proxy.example.com done ``` 8. Download the SAMLtest metadata. ```sh curl https://samltest.id/saml/sp > /opt/satosa/etc/sp.xml curl https://samltest.id/saml/idp > /opt/satosa/etc/idp.xml ``` 9. Generate the proxy metadata. (How you do this changes in future releases of SATOSA.) ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc satosa-saml-metadata proxy_conf.yaml metadata.key metadata.crt --split-frontend --split-backend --dir /opt/satosa/etc xmllint --format /opt/satosa/etc/Saml2IDP_0.xml > /opt/satosa/etc/proxy-idp.xml xmllint --format /opt/satosa/etc/Saml2_0.xml > /opt/satosa/etc/proxy-sp.xml ``` 10. Edit the proxy metadata files to remove the `<ns1:Signature>` element, else SAMLtest will be unable to load them due to an invalid signature. 11. Upload the proxy metadata to SAMLtest (https://samltest.id/upload.php) 12. SAMLtest doesn't release the eduPerson Targeted ID attribute, so you'll need to change the last three lines of /opt/satosa/etc/internal_attributes.yaml to the following (and before anyone says anything, NEVER USE AN EMAIL ADDRESS AS AN IDENTIFIER---this is just a quick hack to get SATOSA working): ``` hash: [mail] user_id_from_attrs: [mail] user_id_to_attr: mail ``` 13. Start SATOSA: ```sh . /opt/satosa/bin/activate cd /opt/satosa/etc gunicorn -b0.0.0.0:443 --keyfile https.key --certfile https.crt satosa.wsgi:app ``` 14. At this point you should be able to perform an IdP test (https://samltest.id/start-idp-test/) by specifying the entity ID of the proxy's front end, e.g., https://example.com/Saml2IDP/proxy.xml. The SAMLtest SP will request authentication by your proxy IdP, causing your proxy SP to request authentication by the SAMLtest IdP. If everything works right, you will end up back at the SAMLtest SP: SAMLtest SP ---AuthnRequest---> SATOSA front end (IdP)/back end (SP) ---AuthnRequest---> SAMLtest IdP SAMLtest SP <---AuthnResponse--- SATOSA front end (IdP)/back end (SP) <---AuthnResponse--- SAMLtest IdP I hope this helps other adopters. If you have any questions, please reply on list so everyone can benefit from the discussion. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

6 years, 4 months

1
0
0 0

MDQ ssl handshake issues

by hannah.short＠cern.ch

Hi Satosa Users List, Firstly, I think my registration for this email list is still pending (or emails are being swallowed by a spam filter somewhere…) is anyone able to approve? Otherwise, maybe there’s simply no traffic :) I’m hitting an issue when coming back from my discovery service (PyFF) to Satosa. At the point where Satosa looks up the IdP/SP in PyFF it fails with a bad SSL handshake. Satosa is running with Docker, as is PyFF. Specific error: requests.exceptions.SSLError: HTTPSConnectionPool(host='pyff.cern.ch<http://pyff.cern.ch>', port=443): Max retries exceeded with url: /entities/%7Bsha1%7Dbf0f1310cb092e88484def3c53613f8a10ebde3d (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),)) I imagine this is because my PyFF instance is running with a certificate that is not publicly trusted. I’ve manually added the certificate to the SSL store in the Satosa docker container (and am able to connect with docker exec satosa_container openssl s_client -connect pyff.cern.ch:443<http://pyff.cern.ch:443> ), but am still hitting an exception in the Satosa code. Has anyone come across this? Is there a way to specify additional trusted CAs, or request that the MDQ lookup be more lenient (for testing purposes)? Cheers, Hannah

6 years, 5 months

3
3
0 0

Satosa & Sirtfi

by hannah.short＠cern.ch

Hello, I’m wondering how I can assert Sirtfi for my Satosa SP proxy. Is there an example anywhere of how to assert the assurance profile and contact, or is it expected that this would be done by my federation registrar? Thanks, Hannah

6 years, 6 months

1
0
0 0

How to add encryption cert to metadata

by david.huebner＠daasi.de

Hi all, I want to include a KeyDescriptor for use=encryption in the generated SAML2 metadata. I'm talking about the {host}/Saml2/proxy_saml2_backend.xml endpoint. The following config works (i.e. SATOSA happily accepts encrypted assertions), however the metadata endpoint does *not* include use="encryption": sp_config: key_file: /etc/satosa/credentials/saml2backend.key cert_file: /etc/satosa/credentials/saml2backend.crt On the other hand, the following config does not work (i.e. SATOSA throws an exception, once an encrypted assertion is received), however the metadata endpoint *does* include use="encryption": sp_config: key_file: /etc/satosa/credentials/saml2backend.key cert_file: /etc/satosa/credentials/saml2backend.crt encryption_keypairs: - key_file: /etc/satosa/credentials/saml2backend.key cert_file: /etc/satosa/credentials/saml2backend.crt I'm sure there's an easy solution. Anyone able to help? Cheers, David

6 years, 6 months

2
2
0 0

Backend routing based on inbound ACR (REFEDs MFA use case)?

by jim.faut＠okta.com

I am trying to put this proxy solution in place in order to provide support for the REFEDs MFA profile. Here is what I want to implement: 1. SP sends Auth Req to Satosa front end with REFEDs MFA profile ACR 2. Satosa makes a routing decision based on existence (or not) of the MFA profile in the request 3. If MFA profile exists, forward requests to IDP 1. Otherwise, route to IDP 2. 4a. Routing to IDP 1 for MFA makes an assumption that MFA was performed and then inserts the MFA profile into the returned SAML response 4b. Routing to IDP 2 for non-MFA makes an assumption that MFA was NOT performed and does not modify the response 5. The Satosa front end returns the assertion to the SAML SP I'd like this routing to be dynamic based only on the existence of the MFA profile in the request without having to maintain a static mapping of SP entity IDs. Reviewing the code, it seems like this might be possible in the DecideBackendByRequester micro service, however the functionality there is based on a static lookup table of entity IDs. A dynamic routing might be possible with a similar approach if one is able to obtain the ACR from the request context decorators. Is the ACR information added to the request decorator (internal_data) when the inbound request is processed? Does this seem like a reasonable approach to the problem? Thanks, Jim

6 years, 7 months

1
0
0 0

Attributes removed from SAML Response to Backend

by hannah.short＠cern.ch

Hello, I’m hitting a strange problem; when a successful SAML response is received by the Satosa backend containing a pretty complete attribute statement (see below), the attributes not recognised by the Backend and I see the error “backend received attributes: {}”. I’m currently just testing things and haven’t changed the internal_attributes.yaml from the example. My IdP is currently just the SimpleSAMLphp userpass example with some mocked up SAML attributes. I wondered whether the attribute Name Format is incorrect, but I don’t see where this can be configured within Satosa. Has anyone else hit this problem? Thanks in advance, Hannah ==================== <saml:AttributeStatement> <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="eduPersonTargetedID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">123456789</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">Test</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="displayName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">Test Person</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test at cern.ch</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement>

6 years, 7 months

2
2
0 0

RelayState being set to "None"

by xenophon＠irtnog.org

Dear all, Scott Koranda fixed this problem in the following pysaml2 pull request: https://github.com/IdentityPython/pysaml2/pull/502 Thank you, Scott! Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 1 month

1
0
0 0

SATOSA sets the NameID format to "transient" but it should be persistent

by xenophon＠irtnog.org

Niels writes: > I think you need to set the name id format in the frontend config like > so: I tested this and unfortunately, it doesn't work. On further inspection this SP includes in its AuthnRequest a NameIDPolicy element with a format of "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified". This overrides the NameIDFormat I specified in the SP's metadata. It also overrides the IdP configuration setting you told me to change. I've opened a ticket with the vendor, asking them to conform to SAML2int (which recommends omitting the NameIDPolicy element entirely), but it's unlikely that will change anything. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 1 month

1
0
0 0

RelayState being set to "None"

by xenophon＠irtnog.org

Hello again, We have a SP that sends a SAMLRequest without a RelayState. SATOSA's SAMLResponse includes a RelayState of "None". This causes the SP to redirect the user to a non-existent URL. Is this a bug in SATOSA, for blindly serializing a Python None value? Or is this a bug in the SP, for not including a valid RelayState value with its SAMLRequest? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
2
0 0

SATOSA sets the NameID format to "transient" but it should be persistent

by xenophon＠irtnog.org

Dear all, How do I force SATOSA to issue a persistent NameID for a given SP? The SP's metadata includes the relevant NameIDFormat element inside the SPSSODescriptor element: https://gist.github.com/xenophonf/bc802a33a2e9caa2457e355c5b9d1651 However, SATOSA still issues a transient NameID in its SAML AuthnResponse. What's especially frustrating is that I have this working for another SP, so I'm not sure what I'm missing beyond the NameIDFormat in the SP metadata. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
1
0 0

Different discovery service for different SPs

by xenophon＠irtnog.org

Dear all, Is it possible to use a different discovery service depending on the SP that sent a SAML AuthnRequest to SATOSA, or do I have to do that in the discovery service's frontend somehow? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
2
0 0

COmanage, Shibboleth, and SATOSA

by xenophon＠irtnog.org

So here's the next question, related to passing unmodified assertions from SATOSA to a SP, specifically COmanage and Shibboleth: What's the right way to bypass the scope checks Shibboleth usually performs on ePPN/ePTID/ePUID? I'm using the following PrimaryIdentifier configuration: ```yaml module: primary_identifier.PrimaryIdentifier name: PrimaryIdentifier config: ## look for identifiers in this order (first match wins) ordered_identifier_candidates: - attribute_names: - epuid - attribute_names: - eppn - name_id name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent - attribute_names: - eppn - edupersontargetedid - attribute_names: - eppn - add_scope: issuer_entityid attribute_names: - name_id name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent - add_scope: issuer_entityid attribute_names: - edupersontargetedid primary_identifier: "uid" clear_input_attributes: false ``` Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
2
0 0

COmanage, Shibboleth, and SATOSA

by xenophon＠irtnog.org

> So here's the next question, related to passing unmodified assertions > from SATOSA to a SP, specifically COmanage and Shibboleth: What's the > right way to bypass the scope checks Shibboleth usually performs on > ePPN/ePTID/ePUID? I'd like to add that I tried the following: - removed the Scope element from the SATOSA IdP metadata - changed the attribute mappings in Shibboleth to use StringAttributeDecoder instead of ScopedAttributeDecoder - both of the above together Shibboleth logs the following: ``` 2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: removed value at position (0) of attribute (eppn) from (https://proxy-auth.example.com/satosa) 2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: no values left, removing attribute (eppn) from (https://proxy-auth.example.com/satosa) ``` Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
3
0 0

No assertions in SATOSA's SAML responses

by xenophon＠irtnog.org

Dear all, I need help understanding why SATOSA isn't passing the IdP assertions through to an SP. SATOSA sends it a successful authentication response, but it's devoid of any attributes. I know that SATOSA gets the right assertion from the IdP because there's a "backend received attributes" log entry that includes the expected values. I see that the PrimaryIdentifier plugin correctly identifies the ePPN because there's a "PRIMARY_IDENTIFIER: Setting attribute uid" log entry. I also see the LdapAttributeStore plugin skip processing, as expected. But when SATOSA routes the request to the Saml2IDP frontend, it logs the following: ``` Filter: [] returning attributes {} ``` And then the SAML response doesn't include any attributes. Here's my complete configuration except for passwords and keying material: https://gist.github.com/xenophonf/d07ab00a30e5559674936e3a549d0141 What am I missing? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

7 years, 2 months

2
4
0 0

SAML2 frontend NameID format unspecified (or email)

by skoranda＠gmail.com

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

7 years, 3 months

1
0
0 0

HTTP 404 accessing Saml2/acs/post

by xenophon＠irtnog.org

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."

7 years, 3 months

1
0
0 0

HTTP 404 accessing Saml2/acs/post

by xenophon＠irtnog.org

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."

7 years, 4 months

1
0
0 0

Fwd: PKCE support

by roland＠catalogix.se

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 >

7 years, 6 months

2
1
0 0

PKCE support

by janusz.ulanowski＠heanet.ie

Hi, Just curious. Will be PKCE supported in oidc-frontend? Thanks, -- Janusz

7 years, 6 months

1
0
0 0

how to get certificate verification on backend calls

by fox＠washington.edu

How can I get the https gets on the backend processes to verify certificates? Jim

7 years, 7 months

4
7
0 0

need email nameid

by fox＠washington.edu

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

7 years, 7 months

1
0
0 0

updated SATOSA LDAP attribute store and breaking change

by skoranda＠gmail.com

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

7 years, 7 months

1
0
0 0

required attributes microservice

by skoranda＠gmail.com

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

7 years, 7 months

1
0
0 0

Problem with Dynamics 365 Portal

by admin＠ifmsa.se

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

7 years, 7 months

3
5
0 0

metadata management for SATOSA with pyFF

by skoranda＠gmail.com

Hi, I am planning to aggregate and manage a couple of different sources of SAML metadata using pyFF to then expose it for consumption by SATOSA. My first thought was to have pyFF dump an XML of the aggregate to the file system and point SATOSA (really pysaml2) at it. But I don't see that the "local" method for SATOSA/pysaml2 to consume metadata ever refreshes what it finds on the file system--it appears to read it once but never again. I need SATOSA to be consuming "fresh" metadata at least every 24 hours. A second option might be to leverage the pysaml2 "loader" functionality and pass in my own callable for reading in the metadata from the file system periodically. But again I don't see that once pysaml2 has the internal representation of the metadata that it would ever invoke my callable again. Is that true? So what I will probably do is operate pyFF as a MDQ server and leverage the pysaml2 "mdq" functionality. How are other SATOSA deployers making sure that SATOSA has "fresh" SAML metadata? Thanks, Scott K

7 years, 8 months

3
3
0 0

"Not destined for me!"

by fox＠washington.edu

We have a satosa instance running as a social-saml gateway: Frontend=saml; backend=google. It is behind Apache and accessed by mod_rewrite, essentually: RewriteRule ^/(.*)$ https://localhost:7445/$1 [P] This works, but the https seems unnecessary. It would be more efficient to use simple http for the localhost rewrite. However, that fails with a "Not destined for me!" in request.py's _verify -- simply because http is not https. Is there a way to use simple http but avoid the error? Commenting out the "raise OtherError" works, but I'd rather not have to edit the sources. Thanks, Jim Fox University of Washington

7 years, 8 months

1
1
0 0

Saml2 backend returning "Couldn't find the page you asked for!"

by liamr＠umich.edu

I've got SATOSA running with mod_wsgi I'm trying to use OIDC on the frontend and SAML2 on the backend, and I think that I have the SAML stuff misconfigured. Acc'd to /satosa/.well-known/openid-configuration, my OIDC authorization endpoint is https://satosa.example.org/satosa/Saml2/OIDC/authorization but any attempt to interact with that URL returns a 404. The OIDC frontend stuff seems to be working - visiting the URLs with various (in)appropriate requests generates responses. Do I need to do something in addition to setting BASE in proxy_conf.yaml to get SATOSA's routing to work through URLs that aren't immediately off the server root? thanks Liam

7 years, 9 months

1
0
0 0

oidc frontend issue - MissingRequiredAttribute("token_endpoint")

by liamr＠umich.edu

SATOSA won't start If I comment out the db_uri /or/ leave it blank. If I don't assign a db_uri, it *does* get set to None, but I get "MissingRequiredAttribute("token_endpoint")". Traceback (most recent call last): File "/opt/local/satosa/lib/python3.5/site-packages/satosa/proxy_server.py", line 148, in make_app return ToBytesMiddleware(WsgiApplication(satosa_config)) File "/opt/local/satosa/lib/python3.5/site-packages/satosa/proxy_server.py", line 90, in init super().init(config) File "/opt/local/satosa/lib/python3.5/site-packages/satosa/base.py", line 68, in init self.request_micro_services + self.response_micro_services) File "/opt/local/satosa/lib/python3.5/site-packages/satosa/routing.py", line 59, in init for instance in frontends} File "/opt/local/satosa/lib/python3.5/site-packages/satosa/routing.py", line 59, in for instance in frontends} File "/opt/local/satosa/lib/python3.5/site-packages/satosa/frontends/openid_connect.py", line 163, in register_endpoints self._create_provider(endpoint_baseurl) File "/opt/local/satosa/lib/python3.5/site-packages/satosa/frontends/openid_connect.py", line 83, in _create_provider self.provider = Provider(self.signing_key, capabilities, authz_state, cdb, Userinfo(self.user_db)) File "/opt/local/satosa/lib/python3.5/site-packages/pyop/provider.py", line 71, in init self.configuration_information.verify() File "/opt/local/satosa/lib/python3.5/site-packages/oic/oic/message.py", line 877, in verify raise MissingRequiredAttribute("token_endpoint") oic.oauth2.message.MissingRequiredAttribute: Missing required attribute 'token_endpoint'

7 years, 9 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

satosa-users