unable to capture eppn information from SAML2/POST at SP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: unable to capture eppn information from SAML2/POST at SP

Peter Schober
* O'Quinn, Dennis <[hidden email]> [2018-06-12 00:14]:
> Thanks, but, not sure how to apply that guidance.  This is what the
> IdP is sending me.  Are you saying I can override that someway and
> 'change' it to eduPersonPrincipalName?

You're mapping the attribute from 'name="eppn"' to 'id="eppn"',
literally in the attribute-map.xml.
(The only way to make this more obvious -- other than the
documentation explaining that this is what happens -- would be calling
the parameters 'from' instead of 'name' and 'to' instead of 'id'.)

It's the latter (the 'id' you've chosen in your attribute-map.xml)
that triggers the SP's built in checks for the eduPersonPrincipalName
attribute, and that's what's reventing you from using it.

> BTW, Much of the documentation I am reading out there seems to imply
> that the configuration is being done by 'one' entity with access to
> "both" IdP and SP configurations and logs simultaneously.

No. But either way: I pointed out everything that was wrong with that
attribute as sent by the IDP (which was everything can can possibly be
wrong).
While you may not have the power to change it you're still free to
convince the IDP that what it does is wrong and not interoperable.
Assuming you're not the only SP in the world it's likely that the next
SP will then not have to go through your experience, once the IDP
fixes this.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

O'Quinn, Dennis
In reply to this post by Peter Schober
Hi Peter, yes, I found that.  In fact I set the loglevel in Apache to print out the activity I wanted to see which included seeing the setting of the RU environment variable I am setting.  Next step is to confirm that my 'RequestHeaders set' statement is being executed and doing what I want, but, that is Apache not Shibboleth.

RE: the name/id/eppn in the attribute map, yes, I did not understand which parm was setting what, but, Scott set me straight on that and I have switched it to name=eepn, id=eduPersonPrincipalName, and then updated the REMOTE_USER= parm on my Session stanza in shibboleth2.xml to reflect that.

I also restored all the filtering in attribute-policy.xml that I had had to remove to get it to work when using eppn as the id.

Thanks to all for your help.  Very responsive group...

D

Dennis O'Quinn | EDW Infrastructure Engineering | NAE115H @ 2250 MTC
The Home Depot | Marietta Technology Center | 2250 Newmarket Parkway | Marietta, GA  30067
M: Direct: 470.689.4513 | Cell: 470.658.1183 | Internal: 24513
e: [hidden email]



-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Tuesday, June 12, 2018 4:18 AM
To: [hidden email]
Subject: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

* Brent Putman <[hidden email]> [2018-06-11 23:47]:
> >  nor whether that value was propagated to the REMOTE_USER variable
> (which I suspect didn't happen since I am still not getting the
> expected response in my application)....
>
> To check REMOTE_USER or any other variable, just use a simple CGI
> script which prints the environment variables.

FYI, Apache httpd logs the value of REMOTE_USER with every line in its access log. No CGI required.

I haven't yet seen that the OP changed the internal id of the attribute to something other than "eppn" or alternatively changed the default attribute-policy.xml: As I've explained in detail what is being sent here is NOT eppn, so the built-in checks from the SP will reject that.
Unless either the id is changed in the attribute-map.xml (and again in the REMOTE_USER precedence list) or the attribute-policy.xml is changed for "eppn" from the ScopiingRule reference to permitAny.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=Hf3lugoqHOshgE6fjYxswT_vMrNPJxym3pOQknoFq7A&s=97VSMLRnD8anUUvNm6OVoR3cOOufQHTIHvQRHjrhwwk&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

O'Quinn, Dennis
In reply to this post by Peter Schober
Hi Peter, see my previous reply for some of this...  RE: the IdP/SP support philosophy, in our case we are a closed corporate environment and the only 'entities' involved are, of course, our on departments and security controls much of this which is probably not like the more public environment you are used to.  That doesn't give the right to not do it right of course, and I will be discussing this with them.

Regarding the 'environment' concept, this (SAML?) is very oriented towards an educational environment from whence it came...  However, I see that it is (or has) moved out of that realm into a more 'generic' environment.  At the risk of opening a can of worms, I wonder if anyone has given thought to updating the documentation/references/nomenclature to something more generic.  I know that 'some' of my confusion/distraction was based on all the 'edu....' example and references because I was not aware of the historical background relating to SAML/Shibboleth....  Just a thought...

D

-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Tuesday, June 12, 2018 4:23 AM
To: [hidden email]
Subject: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

* O'Quinn, Dennis <[hidden email]> [2018-06-12 00:14]:
> Thanks, but, not sure how to apply that guidance.  This is what the
> IdP is sending me.  Are you saying I can override that someway and
> 'change' it to eduPersonPrincipalName?

You're mapping the attribute from 'name="eppn"' to 'id="eppn"', literally in the attribute-map.xml.
(The only way to make this more obvious -- other than the documentation explaining that this is what happens -- would be calling the parameters 'from' instead of 'name' and 'to' instead of 'id'.)

It's the latter (the 'id' you've chosen in your attribute-map.xml) that triggers the SP's built in checks for the eduPersonPrincipalName attribute, and that's what's reventing you from using it.

> BTW, Much of the documentation I am reading out there seems to imply
> that the configuration is being done by 'one' entity with access to
> "both" IdP and SP configurations and logs simultaneously.

No. But either way: I pointed out everything that was wrong with that attribute as sent by the IDP (which was everything can can possibly be wrong).
While you may not have the power to change it you're still free to convince the IDP that what it does is wrong and not interoperable.
Assuming you're not the only SP in the world it's likely that the next SP will then not have to go through your experience, once the IDP fixes this.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=5xm_dFrF4KEIAh-09quTvG3f-zWjjNU7rCsFr1nb2Tw&s=9v-1-dRAjSbriXn8XhNqXKWkBFfndpfnkv8Btq1JuIo&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

Cantor, Scott E.
> Regarding the 'environment' concept, this (SAML?) is very oriented towards an
> educational environment from whence it came...  However, I see that it is (or
> has) moved out of that realm into a more 'generic' environment.  At the risk of
> opening a can of worms, I wonder if anyone has given thought to updating the
> documentation/references/nomenclature to something more generic.

That would depend on what you think should be changed. For example, SAML attribute names should be URIs. That's not an edu thing, it's a "this is how it's supposed to work" thing.

Our example files don't just include eduPerson attributes, there's a host of sample rules for basic stuff in there.

Scoping, to use another example, is not an edu thing, but a Shibboleth thing because I understood the implications of federated identifiers a lot earlier than the rest of the industry, and the bugs in products and services like Office 365 illustrate why I built all that.

Really, nothing in there is edu at all except for the default rules for a few eduPerson attributes, which itself is not inherently edu-specific in most respects.

We do things in SAML right (and we define the rules for what we do), and enterprises don't (*). Documenting "wrong" isn't really a goal.

-- Scott

(*) Yes, this is a generalization, but it's also largely true.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

O'Quinn, Dennis
Well, that wasn't a complaint or attack....  I am a firm believer of doing things the 'right' way from the beginning...  Remember, I am completely unfamiliar with this entire process, so, I don't really have enough of a knowledge base to even *consider* right vs. wrong...  and that's not quite what I meant...  I was thinking more of an 'evolution' as this process grows out of its root environment.  And I am not saying that the evolution is necessary or even applicable...  I am just voicing my own observations as a complete neophyte.

As for examples, yes, I noted the cn/ldap/email/other examples in the attribute map...

What I was really missing (and it is probably out there where I just haven't found it yet) was some sort of primer that tied at least the 3 (or more?) files together a little better...  Like the shibboleth2.xml (and metadata) vs. attribute-map vs. attribute-policy vs. ???...

it took me a bit to grasp the relationships between all of the pieces (i.e., the session info (shibboleth2.xml and metadata info) and the data items that could be manipulated (and how they could be manipulated, e.g. name vs. id in attribute-map) and how they could be filtered (attribute-policy.xml)...

I know that information is there collectively, but, if you have zero exposure to this stuff, then it's a little hard to piece it all together.

Also, I get the distinct impression from some of the group members that there is a pretty high expectation (or assumption?) of fore-knowledge on behalf of the users asking questions.   And that is reasonable given the relative levels of expertise between some of the responders vs. the users posting questions....  I certainly applaud your level of responsiveness....  I feel quite guilty with the level of responsiveness given the elementary level of some (or all) of my questions when someone that is writing the code for this project responds...  I think you guys may want to consider bumping your responses up to the really complex stuff and letting others in the group handle the little stuff...  That may reduce your load quite a bit...

And again, thanks for all the help with my 'education' on these concepts and processes...  It was really useful and appreciated...

Dennis


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Tuesday, June 12, 2018 9:00 AM
To: Shib Users <[hidden email]>
Subject: RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

> Regarding the 'environment' concept, this (SAML?) is very oriented
> towards an educational environment from whence it came...  However, I
> see that it is (or
> has) moved out of that realm into a more 'generic' environment.  At
> the risk of opening a can of worms, I wonder if anyone has given
> thought to updating the documentation/references/nomenclature to something more generic.

That would depend on what you think should be changed. For example, SAML attribute names should be URIs. That's not an edu thing, it's a "this is how it's supposed to work" thing.

Our example files don't just include eduPerson attributes, there's a host of sample rules for basic stuff in there.

Scoping, to use another example, is not an edu thing, but a Shibboleth thing because I understood the implications of federated identifiers a lot earlier than the rest of the industry, and the bugs in products and services like Office 365 illustrate why I built all that.

Really, nothing in there is edu at all except for the default rules for a few eduPerson attributes, which itself is not inherently edu-specific in most respects.

We do things in SAML right (and we define the rules for what we do), and enterprises don't (*). Documenting "wrong" isn't really a goal.

-- Scott

(*) Yes, this is a generalization, but it's also largely true.
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=1_W5TKLhfn9lL4d035n3lYKNZrD46pXTBePCnY_dLXE&s=APhyFl6zEoSKN3Sj-Bj7dTV7u32r12FFjBTdoRpTAL0&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

Peter Schober
In reply to this post by O'Quinn, Dennis
* O'Quinn, Dennis <[hidden email]> [2018-06-12 14:11]:
> RE: the name/id/eppn in the attribute map, yes, I did not understand
> which parm was setting what, but, Scott set me straight on that and
> I have switched it to name=eepn, id=eduPersonPrincipalName

While you can certainly do that (it's an arbitrary only internally
meaningful string) I would not call it "eduPersonPrincipalName" mainly
because IT IS NOT AN eduPersonPrincipalName ATTRIBUTE.

Keeping "eduPersonPrincipalName" as the name works around the issue
that the software stops protecting it (the way it protects the
internal attribute with an id of "eppn"), but that doesn't make it
right -- or less confusing for your co-workers or successors -- to
even more explicitly call it something which -- as I have pointed
out -- it is not.
Call it "user-id" or "broken-crap-from-clueless-idp". Or whatever.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

O'Quinn, Dennis
Thank you sir...  was just trying to make it fit into the paradigm of the rest of the product.  I will come up with my own 'broken' standard and reconfigure...  Esp. since now (before going production) is certainly the time to do it...

D



-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Tuesday, June 12, 2018 9:29 AM
To: [hidden email]
Subject: Re: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

* O'Quinn, Dennis <[hidden email]> [2018-06-12 14:11]:
> RE: the name/id/eppn in the attribute map, yes, I did not understand
> which parm was setting what, but, Scott set me straight on that and I
> have switched it to name=eepn, id=eduPersonPrincipalName

While you can certainly do that (it's an arbitrary only internally meaningful string) I would not call it "eduPersonPrincipalName" mainly because IT IS NOT AN eduPersonPrincipalName ATTRIBUTE.

Keeping "eduPersonPrincipalName" as the name works around the issue that the software stops protecting it (the way it protects the internal attribute with an id of "eppn"), but that doesn't make it right -- or less confusing for your co-workers or successors -- to even more explicitly call it something which -- as I have pointed out -- it is not.
Call it "user-id" or "broken-crap-from-clueless-idp". Or whatever.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=vzkl1dz86XXVUbX86Iv7xs7gQ0C3rrJtfGAaRvmxAbY&s=9yl7_BF4OxWj0iXw6-N02BWB_j9pAwyDqO2FqpO5830&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

Cantor, Scott E.
In reply to this post by O'Quinn, Dennis
> Well, that wasn't a complaint or attack....

No, I didn't think it was.
 
> What I was really missing (and it is probably out there where I just haven't
> found it yet) was some sort of primer that tied at least the 3 (or more?) files
> together a little better...  Like the shibboleth2.xml (and metadata) vs. attribute-
> map vs. attribute-policy vs. ???...

Yes, that's a major gap (though the V3 docs I think will be a bit tighter in that respect), and there isn't one because this project isn't resourced to do documentation as a core deliverable. All of that work has been best effort by the developers, mostly me, in the extremely limited time available in between doing the work that's actually been recognizably funded. As a result, the docs are largely about reference material and documenting how to do things and very little on concepts. That also stems from the fact that it's a very hard thing to write and there are roughly zero tech writers out there who understand SAML well and exactly zero willing to do any work for us. We've tried, believe me.

> Also, I get the distinct impression from some of the group members that there
> is a pretty high expectation (or assumption?) of fore-knowledge on behalf of
> the users asking questions.

Of SAML, yes. Much like with an LDAP server, the docs aren't generally there to teach anybody LDAP. But there aren't good resources anywhere on the real nuts and bolts of it and most people's exposure to it, if they have any, is via a lot of broken, sloppy, and immature practice that's fairly endemic to commecial SAML.
 
> I think you guys may want to consider bumping your responses up to the really
> complex stuff and letting others in the group handle the little stuff...  That may
> reduce your load quite a bit...

I mostly do unless it's a very quick response.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

Peter Schober
In reply to this post by O'Quinn, Dennis
* O'Quinn, Dennis <[hidden email]> [2018-06-12 15:22]:
> I know that information is there collectively, but, if you have zero
> exposure to this stuff, then it's a little hard to piece it all
> together.

I found this to be quite helpful:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPGettingStarted
but if you're being thrown in at the deep end, having to deal with
IDPs that have no clue whatsoever (meaning you as the SP have to work
around all kinds of weird, not recommended, nonsensical and/or
outright wrong/illegal bahaviour) no amount of properly chosen
software defaults will save you from learning how to configure/use the
software.

It's the refusal of most commercial entities in this space (from
home-grown SP software to "cloud" IDPs) to stick to sane, properly
chosen defaults and behaviour that doesn't bend the spec until it's
unrecognizsable), that causes work for everyone else.

The sad part is that those learning about the tech in these
environments have no idea that there would even be better ways of
doing things (were stuff "just works"), because all they've ever
seen/known is manual, bilateral, arbitrary twisting and turning of
their respective software "until it works" (or copying the worst
offenders because they're popular due to other factors), without any
regard to how it's intended to be used.

(Sending a local userid as a transient NameID -- anytime. "No we don't
support attributes, you must send this weird crap in this weird place,
we don't look elsewhere" -- sure! "We don't even look at NameID
formats, that's what all the cloud vendors are doing, too, our
customer want it this way" -- any day. etc.pp.)

> Also, I get the distinct impression from some of the group members
> that there is a pretty high expectation (or assumption?) of
> fore-knowledge on behalf of the users asking questions.

There's no way anyone could negate a sentence about the impressions
someone else may get or not, but it doesn't match my personal views:
Cross-organisational single sign-on is a highly technical field, so at
the very least the same required skill set should be employed as for
any other similarly involved technical topic. (Esp one also involving
distributed computing, large-scale deployments, cryptography, identity
management, etc.)

What's non-optional for a good experience is the ability to ask
technical questions and trying to understand the answers others have
taken their time to provide -- including asking some more if the
answers themselfs are unclear, as will often be the case in highly
technical communities.
(It may also be a dying skill, not sure.)

> I think you guys may want to consider bumping your responses up to
> the really complex stuff and letting others in the group handle the
> little stuff...  That may reduce your load quite a bit...

Being one of those "others" I have some 4000+ posts in this list's
archives that say "I'm trying!" as good as I can.

Though I don't agree with the implication that answers from highly
qualified people (e.g. Scott) will *necessarily* provide for a worse
experience for newcomers.  Conversely I doubt that more answers from
people who only understand small parts of any given problem scenario
will *necessarily* improve it. That latter still hasn't stopped me
from trying.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: unable to capture eppn information from SAML2/POST at SP

John Dennis
In reply to this post by Cantor, Scott E.
On 06/11/2018 06:35 PM, Cantor, Scott wrote:
> On 6/11/18, 6:29 PM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:
>
>> BTW, Much of the documentation I am reading out there seems to imply that the configuration is being done by 'one'
>> entity with access to "both" IdP and SP configurations and logs simultaneously.
>
> What I said notwithstanding, certainly it is true that it's impossible  to test and operate an SP effectively without an IdP, and if you don't control *an* IdP, you will pay for it. That doesn't imply you control every IdP you work with, but if you try and run an SP without one, you'll fail in various ways eventually simply due to lack of robust testing. SSO systems have two halves and you either run both or you eventually pay for it in reliability. You can't wish that need away.
>
> (The best choice of a simple one-off IdP is not something I can really answer. I doubt a Shibboleth IdP is a good choice for most as it's more than one would need, but I don't have to answer that question since my primary OSU role is running one, so my gap these days is the opposite, having control over SPs to test with.)

Ipsilon is a relatively simple IdP to set up. You can run a test
instance of Ipsilson from a Git clone, using the quickrun.py script.
https://pagure.io/ipsilon

There is also Keycloak, not as simple as Ipsilon but not overly
difficult. https://www.keycloak.org/

Unfortunately SAML is one of those technologies you need to have a
reasonable understanding of before you start trying to deploy it. If you
don't invest some time in learning the core concepts you'll frustrate
yourself, take it from someone who learned that lesson the hard way. I'm
going to guess others on this list might agree. To that end a good
introduction is the SAML Technical Overview published by OASIS, the body
that controls the SAML specs.

https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

Also don't be afraid to read the various specs, there is good
information in them:

https://docs.oasis-open.org/security/saml/v2.0/


--
John Dennis
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: unable to capture eppn information from SAML2/POST at SP

Peter Schober
* John Dennis <[hidden email]> [2018-06-12 18:42]:
> Ipsilon is a relatively simple IdP to set up. You can run a test
> instance of Ipsilson from a Git clone, using the quickrun.py script.

Never heard of. Ah, liblasso + python.
Of course SimpleSAMLphp and pysaml2 (pure Python) are options, too.

> There is also Keycloak, not as simple as Ipsilon but not overly difficult.

I personally found that too limited/limiting. Yes, it has a GUI for
all things under the sun, but that was mostly annoying or didn't
behave as indicated and often I completely failed to get it to behave
in a way I wanted (say, saml2int).

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

Alan Buxey
In reply to this post by O'Quinn, Dennis
hi,

> Thank you sir...  was just trying to make it fit into the paradigm of the rest of the product.  I will come up with my own 'broken' standard and reconfigure...  Esp. since now (before going production) is certainly the time to do it...

please don't try to label it as a broken standard. you noted yourself
that there appeared to be a lot of fore-knowledge required for some
things and this is true of some
attributes/names/methods. I would suggest you read up on ePPN if you
want to use that (to eg copy examples/docs) - there's a whole body
looking after that
namespace/usage (same for schac* too).  you can use plenty of other
standard, documented SAML attributes :)

alan
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

O'Quinn, Dennis
Well, until I know (and understand) all the moving parts better, any standard I come up with may well be 'broken' as far as the features and safety that a properly configured Shibboleth may offer...

After I dig a little more, I intend to go back to Peter for a better definition of 'broken' in my case, since, I don't even know enough yet to know *what* would be broken, much less where or how....


-----Original Message-----
From: users <[hidden email]> On Behalf Of Alan Buxey
Sent: Wednesday, June 13, 2018 5:12 AM
To: Shib Users <[hidden email]>
Subject: Re: [EXTERNAL] Re: unable to capture eppn information from SAML2/POST at SP

hi,

> Thank you sir...  was just trying to make it fit into the paradigm of the rest of the product.  I will come up with my own 'broken' standard and reconfigure...  Esp. since now (before going production) is certainly the time to do it...

please don't try to label it as a broken standard. you noted yourself that there appeared to be a lot of fore-knowledge required for some things and this is true of some attributes/names/methods. I would suggest you read up on ePPN if you want to use that (to eg copy examples/docs) - there's a whole body looking after that namespace/usage (same for schac* too).  you can use plenty of other standard, documented SAML attributes :)

alan
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=MtgQEAMQGqekjTjiAhkudQ&r=mn6DeBt1nj8Oqx06pdIK0_n5EfK6FeVHgdjBNpchyro&m=hVrKX1zkarhtyGaNs2qHYEGiHUKb1ulTeX9Vx8-HqNc&s=5CjIKUT2RgNRLpMf4tZn-FDEVfdYb4HY_7nF1bNAp5o&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
12