Entity ID = URI ?
smartin
(The connection ID should be a valid URL complying to the RFC1738.Only
alphanumeric characters and $&'-_.,;=+!*()~/% may be used in entity
ids.)
Up until now I thought that any value was OK. The SAML2 standard
mandates that Entity ID must be an URI? Why in the SimpleSAMLphp
examples (metadata-templates) there are Entity ID that aren't URIs
(Ex. http://code.google.com/p/simplesamlphp/source/browse/trunk/metadata-templates/saml20-sp-remote.php
)?
Olav Morken
I believe most implementations will accept more or less any string as an
entity ID. However, the example should not reflect that, but should use
proper URIs.
I have fixed the example in saml20-sp-remote. As for the Google SP, I
don't think I can change that one, as it is determined by Google.
--
Olav Morken
Hans Zandbelt
> On Thu, Aug 27, 2009 at 02:57:19 -0700, smartin wrote:
>> Currently in Janus it seems Entity ID must be an URI.
>> (The connection ID should be a valid URL complying to the RFC1738.Only
>> alphanumeric characters and $&'-_.,;=+!*()~/% may be used in entity
>> ids.)
>>
>> Up until now I thought that any value was OK. The SAML2 standard
>> mandates that Entity ID must be an URI? Why in the SimpleSAMLphp
>> examples (metadata-templates) there are Entity ID that aren't URIs
>> (Ex. http://code.google.com/p/simplesamlphp/source/browse/trunk/metadata-templates/saml20-sp-remote.php
>> )?
>
> I believe most implementations will accept more or less any string as an
> entity ID. However, the example should not reflect that, but should use
> proper URIs.
FYI: Geneva Server (beta2) requires URIs for Entity IDs, although not
very consistently. I wouldn't know any reason for doing so, however, other
than taking the spec very strictly.
Hans.
--
Hans Zandbelt hans.z...@surfnet.nl
SURFnet http://www.surfnet.nl
Jacob Christiansen
as URIs. I also remember to have read it in the spec somewhere. Is
there a good reason for not doing it or doing it?? Please comment.
Regards
Peter Schober
> Is there a good reason for not doing it or doing it?? Please
> comment.
E.g.
http://www2.computer.org/portal/web/csdl/doi/10.1109/MSP.2008.31
https://spaces.internet2.edu/display/dsaml/Distributed+Dynamic+SAML
-peter
Jacob Christiansen
What is the content of the article http://www2.computer.org/portal/web/csdl/doi/10.1109/MSP.2008.31?
? I do not have access to the article. Just want to know a bit more
before buying it.
Regards
smartin
into something is generally a secondary issue. However, SAML 2.0
defines a fairly obvious way of obtaining metadata about a given
entity by resolving an entityID URL (see section 4.1 of the SAML
Metadata Specification).
For this reason, it can be prudent to select a URL that you control
directly and could resolve at some future date. This is generally not
difficult to do because a well-chosen name that has good persistence
will usually correspond to a service's public/logical DNS name. When
you offer a service to significant numbers of users, getting them to
switch to a different name after they're used to one is effectively
impossible." [1]
"Two mechanisms are provided for an entity to publish (and for a
consumer to resolve the location of) metadata documents: via a "well-
known-location" by directly dereferencing the entity's unique
identifier (a URI variously referred to as an entityID or providerID),
or indirectly by publishing the location of metadata in the DNS." [2]
[1] https://spaces.internet2.edu/display/SHIB2/EntityNaming
[2] http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
(Section 4.1)
Nate Klingenstein
Your memory is excellent! The entityID is required to be a URI by the
SAML 2.0 Core spec. Please check section 8.3.6.
Take care,
Nate.
Ian Barnett
merely RECOMMENDED.
Sec 8.3.6 says
"The syntax of such an identifier is a URI of not more than 1024
characters in length. It is
RECOMMENDED that a system entity use a URL containing its own domain
name to identify itself."
Almost all SAML-based implementations allow you to use any string that
is less than 1024 characters. To be as flexible as possible, one
should not assume that the EntityID will be a URI.
Just my $0.02 --
Ian Barnett
Peter Schober
> Not to be too nit-picky -- but this is not REQUIRED per the spec it
> is merely RECOMMENDED.
>
> Sec 8.3.6 says
>
> "The syntax of such an identifier is a URI of not more than 1024
> characters in length. It is
> RECOMMENDED that a system entity use a URL containing its own domain
> name to identify itself."
The URI is required by the very sentence you quoted above (the first
one). There's *no* way I can read "The syntax ... is a URI" that does
*not* make URIs a requirement. Stating the opposite is just nonsense
(or maybe you just need glasses or switch fonts, becaue URI != URL).
Of course URLs are recommended and should resolve to a copy of an
entity's own metdata (possibly even signed by a third party).
But URNs are still valid as well, because they are URIs.
> Just my $0.02
Which makes this my 0.0139178845 EUR, per Google -- speaking of which:
'google.com' is not a valid EntityId.
-peter
Nate Klingenstein
RL 'Bob' Morgan
> Not to be too nit-picky -- but this is not REQUIRED per the spec it is
> merely RECOMMENDED.
The RECOMMENDED part is the part that says it should be a URL containing
its own domain name.
"The syntax of such an identifier is a URI" seems perfectly clear to me.
The "is" means the identifier MUST have URI syntax, which is not "any
string".
The usage of URIs in the SAML specs is further well-defined by section
1.3.2 of saml-core:
1.3.2 URI Values
All SAML URI reference values have the type xs:anyURI, which is built in
to the W3C XML Schema Datatypes specification [Schema2]. Unless otherwise
indicated in this specification, all URI reference values used within
SAML-defined elements or attributes MUST consist of at least one
non-whitespace character, and are REQUIRED to be absolute [RFC 2396].
Note that the SAML specification makes extensive use of URI references as
identifiers, such as status codes, format types, attribute and system
entity names, etc. In such cases, it is essential that the values be both
unique and consistent, such that the same URI is never used at different
times to represent different underlying information.
There is often an argument as to whether "syntax is a URI" means that the
URI must be from a registered URI scheme and allocated according to the
administration of that scheme. That isn't something that can be
realistically checked by software implementing SAML, so a legal SAML
implementation has only to check that the syntax is correct.
But the intent of using URIs is obvious: trying to get deployers to use
values that are globally unique and assigned in some rational fashion
rather than just making things up that will collide later. The tendency
of deployers just to stick in any old strings anyway is unfortunate but
the way of the world.
> Almost all SAML-based implementations allow you to use any string that
> is less than 1024 characters. To be as flexible as possible, one should
> not assume that the EntityID will be a URI.
The writers of such implementations would argue that they do so in support
of interoperability (or perhaps "ease of deployment") when in fact being
lax on what is an obvious requirement of the spec just creates
interoperability problems, such as those we're spending precious time
discussing here, by encouraging bad deployment practice and penalizing
writers of correct software.
- RL "Bob"
Boudewijn Ector
After having been playing around using simplesamlphp for some time, I've
decided to move on with my project and try to merge some assertions.
My target is getting data from 2 SAML-2 IdPs (one of these is a
SAML-OpenID bridge...) and combining the data into a single assertion.
Attributes from one of the IdP's should be marked in some way or another
(I'd like to express some notion of trust in the originating IdP) in the
resulting assertion.
This merging-action should be done by an instance of SimpleSAMLphp,
which acts as an SP to the other IdPs, but as an IdP to the user.
I've thought about this scenario (I had a look at the attribute
aggregation concept from George Inman, and used it in order to formulate
my own ideas):
1: User goes to my IdP, and selects an IdP to use using the wayf page.
This is a regular setup, let's call the selected IdP the 'primary IdP'.
2: User logs in on his primary IdP, and authentication succeeds.
Assertion is sent back to my IdP.
3: User logs is redirected to my SAML2-OpenID bridge and user
authenticates against some OpenID provider (google for instance).
Assertion is sent back to my IdP.
4: My IdP takes the attributes from the user's first IdP, and merges
these with the attributes provided by the second IdP. It then returns
the complete set of assertions to the SP the user originally requested.
I've had a look at the current architecture of SimpleSAMLphp , does
anybody have a suggestion about where to implement this properly?
I might consider :
- A module. Does this have any disadvantages? A
- An authentication processing filter might be viable too?
I would prefer to reuse as much of the existing code as possible, since
the the second authentication should not be different from the first
(from a code perspective...).
Note:
- I'm not intersted in anything but SAML-2 currently.
- It does not have to be great code, it's just a proof of concept.
Maintainability is nice, but it's not top priority.
- I (and thus SURFnet) will share any work with the community, under the
license of simpleSAMLphp.
Can anybody please be so kind to advise me on this? Furthermore, all
suggestions are welcome too!
Cheers,
Boudewijn
Olav Morken
I assume here that you mean "an authentication source"? That would in
my opinion be the best long-term solution. An authentication source can
call other authentication sources, though there are no examples of this
in simpleSAMLphp at the moment.
> - An authentication processing filter might be viable too?
This would also be possible, but you should be aware that
authentication processing filters are executed for every authentication
request the IdP receives. This means that you need some method to cache
the result from the first time. It is certainly doable, but would look
like a hack to me.
> I would prefer to reuse as much of the existing code as possible, since
> the the second authentication should not be different from the first
> (from a code perspective...).
>
> Note:
>
>
> - I'm not intersted in anything but SAML-2 currently.
> - It does not have to be great code, it's just a proof of concept.
> Maintainability is nice, but it's not top priority.
> - I (and thus SURFnet) will share any work with the community, under the
> license of simpleSAMLphp.
>
>
>
> Can anybody please be so kind to advise me on this? Furthermore, all
> suggestions are welcome too!
If I was to do this, I would create an authentication source which
calls two other authentication sources and merges the result. That
could (for example) be the saml and the openid authentication sources.
To implement such an authentication source, I would have to set up
a call to the authenticate-function of the two sources in much the same
way as done in lib/SimpleSAML/Auth/Default.php. The difference would be
that instead of storing the result from the authentications in the
session object, it would merge them into a single result which it
returns.
--
Olav Morken
Boudewijn Ector
> I assume here that you mean "an authentication source"? That would in
> my opinion be the best long-term solution. An authentication source can
> call other authentication sources, though there are no examples of this
> in simpleSAMLphp at the moment.
>
/modules.
> This would also be possible, but you should be aware that
> authentication processing filters are executed for every authentication
> request the IdP receives. This means that you need some method to cache
> the result from the first time. It is certainly doable, but would looklike a hack to me.
>
That's a good reason to disqualify the option of creating a processing
filter.
Thank you for the advice!
>
> If I was to do this, I would create an authentication source which
> calls two other authentication sources and merges the result. That
> could (for example) be the saml and the openid authentication sources.
>
Okay, that seems okay to me. I'm going to call SAML twice, but that
should be fine too I suppose.
> To implement such an authentication source, I would have to set up
> a call to the authenticate-function of the two sources in much the same
> way as done in lib/SimpleSAML/Auth/Default.php. The difference would be
> that instead of storing the result from the authentications in the
> session object, it would merge them into a single result which it
> returns.
Thank you for pointing that one out to me. I'll have a look at it later
on this day!
Thanks for the advice, I really appreciate it!
Boudewijn Ector
Olav Morken
>
>
> > I assume here that you mean "an authentication source"? That would in
> > my opinion be the best long-term solution. An authentication source can
> > call other authentication sources, though there are no examples of this
> > in simpleSAMLphp at the moment.
> >
> Yes I guess I do so. Just an authentcation source, like the others in
> /modules.
Just to be clear: /modules contains authentication sources, processing
filters, and many other things.
> > This would also be possible, but you should be aware that
> > authentication processing filters are executed for every authentication
> > request the IdP receives. This means that you need some method to cache
> > the result from the first time. It is certainly doable, but would looklike a hack to me.
> >
> That's a good reason to disqualify the option of creating a processing
> filter.
> Thank you for the advice!
> >
> > If I was to do this, I would create an authentication source which
> > calls two other authentication sources and merges the result. That
> > could (for example) be the saml and the openid authentication sources.
> >
> Okay, that seems okay to me. I'm going to call SAML twice, but that
> should be fine too I suppose.
Yes, that should be fine.
> > To implement such an authentication source, I would have to set up
> > a call to the authenticate-function of the two sources in much the same
> > way as done in lib/SimpleSAML/Auth/Default.php. The difference would be
> > that instead of storing the result from the authentications in the
> > session object, it would merge them into a single result which it
> > returns.
> Thank you for pointing that one out to me. I'll have a look at it later
> on this day!
>
>
>
> Thanks for the advice, I really appreciate it!
You are welcome!
--
Olav Morken
Steven_...@brown.edu
>Hi everybody,
>
>
>After having been playing around using simplesamlphp for some time, I've
>decided to move on with my project and try to merge some assertions.
>My target is getting data from 2 SAML-2 IdPs (one of these is a
>SAML-OpenID bridge...) and combining the data into a single assertion.
>Attributes from one of the IdP's should be marked in some way or another
>(I'd like to express some notion of trust in the originating IdP) in the
>resulting assertion.
>This merging-action should be done by an instance of SimpleSAMLphp,
>which acts as an SP to the other IdPs, but as an IdP to the user.
>
It might be helpful if you were to describe the use case you're
trying to address -- it sounds like you're trying to link identities
in some way? There's already been some interesting work done in this
area:
-- David Chadwick's Shintau project.
-- the Shibboleth 2.2.1 SP implementation already supports linking
identities. It can be configured to retrieve attributes from
additional IdPs, merge them with the original set, and present the
union set to the application.
Other work that may be relevant to your use case may be the Delegated
Assertion support that has been added to Shibboleth. This allows a
mid-tier (eg a portal) to obtain receive SAML assertions in the
standard way, and then obtain Delegated Assertions from the issuing
IdP, and then present the Delegated Assertions to backend services on
behalf of the user. More information is available here:
Boudewijn Ector
> It might be helpful if you were to describe the use case you're
> trying to address -- it sounds like you're trying to link identities
> in some way? There's already been some interesting work done in this
> area:
>
the SUFfederatie, and an untrusted OpenID provider (google, hyves,
whatever).
I'm trying to allow users to change some (!) of their attributes, by
having those provided by an OpenID provider.
This allows users to have some control without lowering the trust of our
current federation (since there's no changed data inside the federaion).
The main idea is that due to users being able to edit their OpenID
profile, they are able to change their personal attributes. This
improves the user's privacy within our model.
When an attribute is required by an SP and the attribute is being
provided by both IdP's, they ones from the trusted IdP are preferred.
My SAML2-OpenID bridge just converts the OpenID protocol to SAML2, thus
allowing my main component to just focus on SAML2.
> -- David Chadwick's Shintau project.
>
My target is just adding 1 IdP for improving the user's privacy. Afaik
the Shintau project requires the SP to do some stuff too, although I'm
not quite sure about this anymore.
I read Inman's IEEE paper too by the way, which inspired me more or less
to do this.
> -- the Shibboleth 2.2.1 SP implementation already supports linking
> identities. It can be configured to retrieve attributes from
> additional IdPs, merge them with the original set, and present the
> union set to the application.
>
The Shib SP implementation sounds nice to me but I just use SAML,
shibboleth is not used much in our federation.
> Other work that may be relevant to your use case may be the Delegated
> Assertion support that has been added to Shibboleth. This allows a
> mid-tier (eg a portal) to obtain receive SAML assertions in the
> standard way, and then obtain Delegated Assertions from the issuing
> IdP, and then present the Delegated Assertions to backend services on
> behalf of the user. More information is available here:
>
> https://spaces.internet2.edu/display/ShibuPortal/Home
Seems to be a bit complex, for my targets.