7:33 p.m.
Hello,
Does anyone have a configuration for the SATOSA SAMLMirrorFrontend they
have working and would be willing to share?
I have working configurations for SAMLFrontend (of course), but I want to
understand what changes for a working SAMLMirrorFrontend.
I am having trouble just understanding it from the code, and I cannot find
any documentation that explains it...
Thanks for your consideration,
Scott K
11:51 p.m.
Hi Scott,
for eduTEAMS we are using both frontend flavors.. The only difference we
have between the 2 configs is the use of mirrored frontend, so
"module: satosa.frontends.saml2.SAMLMirrorFrontend"
Find below an ansible template for the config. Anythign between {{ }}
will be replace by ansible for real values, but still I think it is
pretty trivial what needs to go into the file.
Hope this helps,
Niels
=====
# The saml2 frontend talks to SERVICE Providers!
module: satosa.frontends.saml2.SAMLMirrorFrontend
name: Saml2IDP
config:
idp_config:
organization: {display_name: "{{
saml2sp_frontend.organization.display_name }}", name: "{{
saml2sp_frontend.organization.name }}", url: "{{
saml2sp_frontend.organization.url }}" }
contact_person:
- {contact_type: "technical", email_address: "{{
saml2sp_frontend.contact_person.technical.email }}", given_name: "{{
saml2sp_frontend.contact_person.technical.given_name }}" }
- {contact_type: "administrative", email_address: "{{
saml2sp_frontend.contact_person.admin.email }}", given_name: "{{
saml2sp_frontend.contact_person.admin.given_name }}" }
- {contact_type: "support", email_address: "{{
saml2sp_frontend.contact_person.support.email }}", given_name: "{{
saml2sp_frontend.contact_person.support.given_name }}" }
key_file: "{{ proxy_frontend_key }}"
cert_file: "{{ proxy_frontend_cert }}"
metadata:
{{ saml2sp_frontend.metadata | to_nice_yaml | indent(6) }}
entityid: <base_url>/proxy
service:
idp:
scope: ["{{ saml_scope }}"]
endpoints:
single_sign_on_service: [
#The endpoints will be added later when registering
endpoints in the module.
]
name: Proxy IdP
name_id_format:
['urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient']
policy:
default:
attribute_restrictions: null
fail_on_missing_requested: false
lifetime: {minutes: 15}
name_form: urn:oasis:names:tc:SAML:2.0:attrname-format:uri
want_authn_requests_signed: false
xmlsec_binary: "{{ xmlsec_binary }}"
logger:
loglevel: info
rotating: {backupCount: 5, filename: {{ logs_dir
}}/saml2_frontend.log, maxBytes: 500000}
acr_mapping:
"": http://eidas.europa.eu/LoA/low
state_id: <name>
base: <base_url>
endpoints:
single_sign_on_service:
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect': sso/redirect
'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST': sso/post
custom_attribute_release:
"default":
{% for car in custom_attribute_release %}
"{{ car.entityid }}":
exclude: {{car.arp_filter}}
{% endfor %}
# disco_srv must be defined if there is more than one IdP in the
metadata specified above
# disco_srv:
=======
On 24-08-18 18:33, Scott Koranda wrote:
Hello,
Does anyone have a configuration for the SATOSA SAMLMirrorFrontend
they have working and would be willing to share?
I have working configurations for SAMLFrontend (of course), but I want
to understand what changes for a working SAMLMirrorFrontend.
I am having trouble just understanding it from the code, and I cannot
find any documentation that explains it...
Thanks for your consideration,
Scott K
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
12:34 p.m.
New subject: working configuration for SATOSA SAMLMirrorFrontend
Hi Scott,
Our ansible configuration can be found here:
https://github.com/SURFscz/SCZ-deploy/tree/master/roles/satosa
The SamlIdp and SAMLMirrorIdp templates are out of sync because the mirror
conf doesn't get the love the normal IdP receives, but apart from jinja
templating magic there's not much difference.
The idea is that satosa-saml-metadata will create IdP metadata for a unique
IdP entityID for each configured IdP on all SAMLbackends or OIDC RP. In our
case the entityID is a concatenation of the [satosa proxy url] + /[backend
module name] + /[base64 encoded IdP entityID] which are also the base for the
endpoints:
entityID="https://proxy.scz-vm.net/md/SamlMirrorIdP.xml/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA=="
Location="https://proxy.scz-vm.net/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA==/
sso/redirect"
I realise our code might differ slightly from upstream because of PR #171 as we
introduced the SAMLMirroredBackend module as well...
YMMV ;)
Regards,
Martin
On Friday, August 24, 2018 6:33:21 PM CEST Scott Koranda wrote:
Hello,
Does anyone have a configuration for the SATOSA SAMLMirrorFrontend they
have working and would be willing to share?
I have working configurations for SAMLFrontend (of course), but I want to
understand what changes for a working SAMLMirrorFrontend.
I am having trouble just understanding it from the code, and I cannot find
any documentation that explains it...
Thanks for your consideration,
Scott K
4:27 p.m.
The idea is that satosa-saml-metadata will create IdP
metadata for a unique
IdP entityID for each configured IdP on all SAMLbackends or OIDC RP. In our
case the entityID is a concatenation of the [satosa proxy url] + /[backend
module name] + /[base64 encoded IdP entityID] which are also the base for the
endpoints:
entityID="https://proxy.scz-vm.net/md/SamlMirrorIdP.xml/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA=="
Location="https://proxy.scz-vm.net/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA==/
sso/redirect"
Thanks Martin (and Niels). With your hints and further study I think I
have a solid grasp on the SAMLMirrorFrontend now.
I do have a small (and not urgent) request:
Some of the SAMLMirrorFrontend logic "leaks" over into the SAMLBackend
class in the method start_auth(). That method has some special logic to
inspect the context and detect that a dynamic IdP has been targeted. If
it finds the dynamic IdP in the context it calls
entity_id = urlsafe_b64decode(entity_id).decode("utf-8")
and then sends a SAML authentication request off to that
federated/authenticating IdP.
I think the SAMLBackend class should not have to be aware of any details
of how the SAMLMirrorFrontend class works.
My thought is that there should be a standard way for the SAMLBackend to
be "signalled" that it should use a specific IdP. Then the logic for its
start_auth() method could be
- am I being signalled to use a specific IdP? Yes, go do it
- else, am I federated with only one IdP? Yes, go do it
- else go do IdP discovery
Thoughts? Ivan?
Thanks,
Scott K
9:36 p.m.
New subject: working configuration for SATOSA SAMLMirrorFrontend
Hello,
On Mon, 27 Aug 2018 at 16:27, Scott Koranda <skoranda at gmail.com> wrote:
I do not see a direct relation between the saml2-backend (start_auth()
function) and the SAMLMirrorFrontend. The key defined and used through
the context object contains the '_MIRROR_' part, but this is only
something that we understand - not the compiler/interpreter. For the
code, there is no direct coupling between the respective modules.
The mechanism by which information is passed between the frontend and
backend modules is
- either, through the Context
- or, through the InternalData (InternalRequest and InternalResponse)
(choice depends on the kind of data that needs to be communicated)
The SAMLMirrorFrontend sets a flag (by invoking decorate() with the
appropriate key) in the environment (the context).
The backend checks the environment and if a flag is set it acts appropriately.
Also, see pull request #191 that refactors the code to make the above clearer:
https://github.com/IdentityPython/SATOSA/pull/191
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
The idea is that satosa-saml-metadata will create
IdP metadata for a unique
IdP entityID for each configured IdP on all SAMLbackends or OIDC RP. In our
case the entityID is a concatenation of the [satosa proxy url] + /[backend
module name] + /[base64 encoded IdP entityID] which are also the base for the
endpoints:
entityID="https://proxy.scz-vm.net/md/SamlMirrorIdP.xml/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA=="
Location="https://proxy.scz-vm.net/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA==/
sso/redirect"
Thanks Martin (and Niels). With your hints and further study I think I
have a solid grasp on the SAMLMirrorFrontend now.
I do have a small (and not urgent) request:
Some of the SAMLMirrorFrontend logic "leaks" over into the SAMLBackend
class in the method start_auth(). That method has some special logic to
inspect the context and detect that a dynamic IdP has been targeted. If
it finds the dynamic IdP in the context it calls
entity_id = urlsafe_b64decode(entity_id).decode("utf-8")
and then sends a SAML authentication request off to that
federated/authenticating IdP.
I think the SAMLBackend class should not have to be aware of any details
of how the SAMLMirrorFrontend class works.
My thought is that there should be a standard way for the SAMLBackend to
be "signalled" that it should use a specific IdP. Then the logic for its
start_auth() method could be
- am I being signalled to use a specific IdP? Yes, go do it
- else, am I federated with only one IdP? Yes, go do it
- else go do IdP discovery
Thoughts? Ivan?
2:10 p.m.
Hi,
I do not see a direct relation between the
saml2-backend (start_auth()
function) and the SAMLMirrorFrontend. The key defined and used through
the context object contains the '_MIRROR_' part, but this is only
something that we understand - not the compiler/interpreter. For the
code, there is no direct coupling between the respective modules.
I understand that the name of the key is not the issue.
The issue is that the SAMLBackend method start_auth() contains this
logic:
if target_entity_id:
entity_id = urlsafe_b64decode(target_entity_id).decode()
So it assumes that any target entityID passed through the context has
been base64 encoded.
Only the SAMLMirrorFrontend does that, and only because the URL safe
base64 encoded target entityID is used by the SAMLMirrorFrontend, for
example to construct <SingleSignOnService> URLs.
If I am writing a request micro service or a new front end and I want to
use the SAMLBackend, I shouldn't have to URL safe base64 encode the
entityID before putting it into the context for consumption by the
SAMLBackend. I should just be able to put in the context the entityID
of the IdP I want the SAMLBackend to target with an authentication
request.
Or am I missing some fundamental reason that the entityID must be URL
base64 encoded in the context?
Thanks,
Scott
2:12 p.m.
New subject: working configuration for SATOSA SAMLMirrorFrontend
On Wed, 29 Aug 2018 at 14:10, Scott Koranda <skoranda at gmail.com> wrote:
Hi,
No, you are right. This is special to the SAMLMirrorFrontend. It
should be moved to the point where that frontend sets the value for
the target entityID.
I do not see a direct relation between the
saml2-backend (start_auth()
function) and the SAMLMirrorFrontend. The key defined and used through
the context object contains the '_MIRROR_' part, but this is only
something that we understand - not the compiler/interpreter. For the
code, there is no direct coupling between the respective modules.
I understand that the name of the key is not the issue.
The issue is that the SAMLBackend method start_auth() contains this
logic:
if target_entity_id:
entity_id = urlsafe_b64decode(target_entity_id).decode()
So it assumes that any target entityID passed through the context has
been base64 encoded.
Only the SAMLMirrorFrontend does that, and only because the URL safe
base64 encoded target entityID is used by the SAMLMirrorFrontend, for
example to construct <SingleSignOnService> URLs.
If I am writing a request micro service or a new front end and I want to
use the SAMLBackend, I shouldn't have to URL safe base64 encode the
entityID before putting it into the context for consumption by the
SAMLBackend. I should just be able to put in the context the entityID
of the IdP I want the SAMLBackend to target with an authentication
request.
Or am I missing some fundamental reason that the entityID must be URL
base64 encoded in the context?
Thanks,
Scott
--
Ivan c00kiemon5ter Kanakarakis >:3
2306
days inactive
2311
days old
6 comments
4 participants
participants (4)
-
ivan.kanak＠gmail.com -
martin＠surfnet.nl -
niels.vandijk＠surfnet.nl -
skoranda＠gmail.com