[Shib-Users] Info Shibboleth IdP
Alessandra Giordano
I need to know if Shibboleth IdP can be integrated with applications running under various platforms, including: JBoss, Oracle Application server, Liferay and IIS.
Of course, we are willing to develop appropriate forms of integration, but I wonder if such integration is possible and has already been implemented by someone.
Thanks
________________________________________________________________________________________
Alessandra Giordano
InnovaPuglia S.p.A.
e-mail: a.gio...@innova.puglia.it
Chad La Joie
integration in to things like portals or web servers then that is
normally the SP, not the IdP.
If you're asking if the IdP can be installed in Servlet containers other
than Tomcat the answer is yes. There is documentation out on the Shib
site that shows how to prepare JBoss, Tomcat, and Jetty 7 and some folks
have claimed to have it running in Glassfish, Weblogic, and Websphere.
However, note, *you* are responsible for knowing your container of
choice including the installation and configuration of that container.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
a.gio...@innova.puglia.it
I want to create a single federated authentication method for all these applications using Shibboleth Identity Provider and OpenDS as LDAP directory.
How can I achieve this? I have to make a service provider for any applications that communicates with Shibboleth Identity Provider? All these platforms are compatible with Shibboleth or is it sufficient that the service provider has created SAML compliant?
Chad La Joie
of the box it supports authentication against Kerberos and LDAP or by
means of the Servlet container. It can pull attributes from LDAP
directories and relational databases. It is a standard Java webapp and
so can be deployed in any container that supports the Java Servlet 2.4
spec (which is pretty much any of them).
The SP connects with the applications to be protected and is a web
server module for Apache, IIS, and Netspace/iPlanet server. You must
have at least one per server hosting an application. If you have an
application which supports SAML directly you may be able to interoperate
with Shibboleth however there are lots of variables that determine
whether this will actually work. Before starting with that you should
get a basic understanding of SAML and Shibboleth.
--
a.gio...@innova.puglia.it
Chad La Joie
specific SAML profiles, that is the unit of interoperability within
SAML. There are lots of variables that determine whether two SAML
products can communicate. To the best of my knowledge there are no
major commercial SAML products that can't work with Shibboleth but there
are also no products that work automatically.
a.gio...@innova.puglia.it wrote:
> So if I understand correctly, supone I have a portal that runs under Oracle Application Server: if the portal is compatible SAML it could interact directly with Shibboleth IdP, also realizing additional modules; if the portal is not compatible SAML, I use a service provider before the portal that interacts with Shibboleth IdP, such as Oracle Identity Federation. In the end everything should work, right?
--
ynotlim
This might help.
Create a CAS server that authenticates against Shibboleth and use the
liferay CAS module. Very easy to do.
http://code.google.com/p/casshib/
For the other tools, I'm not sure.
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5534537.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
Eugene Dvorkin
and successfully works with Shibboleth IDP.
I am able to login and read assertions. The problem is with logout
functionality.
User logout locally from my application (sp) by removing cookies and
security context.
But when user click on login button again, my SP initialize new session
to IPd and IDP does not ask for user name/pwd anymore.(it will if I
completely close the browser) It just authenticate the user. I see IDp
issued following cookies (_idp_authn_lc_key,_idp_session) which allows
IDP to bypass login screen. Is there a way to remove those cookies and
force IDP to ask user credentials from this SP? Basically notify Idp
that particular user from this SP logged out? Any java code I can refer
to? I know shibboleth SP module provide this functionality but I am not
using it.
thanks
Scott Cantor
> using it.
The SP implements the SAML logout protocol. If you want to support logout,
then your SP should support it as well. But the IdP does not support it
except via a third party extension.
See millions of past messages and the SLOIssues topic in the wiki.
-- Scott
Eugene Dvorkin
implement SAML logout protocol
Yang, Jack
https://wiki.aai.niif.hu/index.php/ShibIdpSLO
Best Regards!
Jack Yang
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Eugene Dvorkin
Sent: Wednesday, September 15, 2010 12:58 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Logout from IDP
Thanks. I read about SLOIssues. I am searching for details how to
implement SAML logout protocol
-----Original Message-----
From: shibboleth-u...@internet2.edu
[mailto:shibboleth-u...@internet2.edu] On Behalf Of Scott
Cantor
Sent: Wednesday, September 15, 2010 12:37 PM
To: shibbole...@internet2.edu
Subject: RE: [Shib-Users] Logout from IDP
> to? I know shibboleth SP module provide this functionality but I am
not
> using it.
The SP implements the SAML logout protocol. If you want to support
logout,
then your SP should support it as well. But the IdP does not support it
except via a third party extension.
See millions of past messages and the SLOIssues topic in the wiki.
-- Scott
The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.
Eugene Dvorkin
logout on SP side.
Chad La Joie
Spring Security as the SP then you need to contact them. This is the
list for questions related to the Shibboleth software.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
rcrathore
I think it is high time to include Spring Security SAML integration details
in Shibboleth documentation.
Shibboleth developer community needs to work with Spring team to simplify
the integration and make developers' lives easier. Given the increasing
popularity of Spring Security among developers, Shibboleth is running a risk
of being sidelined if it simply ignores reality. A strong headed comment
like
Security as the SP then you need to contact them. This is the list for
disturbing to Spring developers. Spring, being an open source product, will
always be open to integration with any framework and technology that
developers deal with in their day to day lives. It will be a good idea if
contributors of Shibboleth, which is also an open source product, keep their
feet on ground and listen to what developers are looking for.
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5904780.html
Chad La Joie
First, the notion of directing people to other lists. This list is for
the support of Shibboleth software. The Spring forums are for the
support of Spring software. Asking a question about a different piece
of software then what a given forum is meant for will either get you
ignored or result in some one telling you which venue is the appropriate
place to ask such questions. If you'd like to try an experiment go out
to the Spring Security forum and ask them to provide you documentation
and answers to your questions about setting up a Shibboleth IdP.
Assuming you aren't ignored, it probably won't be long before some one
says "this isn't the correct place to ask, go the Shibboleth list".
Second, if you review the list archives, we have asked at various times,
over the years, whether the community thinks a Java-based service
provider is a good use of time. Each time, less than 0.01% (roughly 3-5
our of about 10k) of the known deployers have indicated they were
looking to deploy such a thing. Given that, I think it's pretty clear
that spending time and effort on such work would *not* be listening to
what people want.
Now, that said, if you happen to know of any Spring Security developers,
and they have interest in developing a good SAML module for Spring
Security, then let us know. As stated above we don't have the resources
to write such a thing ourselves but, as a project, we have been doing
this work for about 12 years. I personally would be willing to help
implementers by at least answering some technical questions and, if time
permits, writing and/or reviewing code. I suspect, but can't be
certain, Scott would also be willing to answer technical questions.
On 1/9/11 12:34 PM, rcrathore wrote:
>
> I think it is high time to include Spring Security SAML integration details
> in Shibboleth documentation.
> Shibboleth developer community needs to work with Spring team to simplify
> the integration and make developers' lives easier. Given the increasing
> popularity of Spring Security among developers, Shibboleth is running a risk
> of being sidelined if it simply ignores reality. A strong headed comment
> like
> If you have questions about logout on the SP side and you're using Spring
> Security as the SP then you need to contact them. This is the list for
> questions related to the Shibboleth software. is out of place here and quite
> disturbing to Spring developers. Spring, being an open source product, will
> always be open to integration with any framework and technology that
> developers deal with in their day to day lives. It will be a good idea if
> contributors of Shibboleth, which is also an open source product, keep their
> feet on ground and listen to what developers are looking for.
>
>
>
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Michael R. Gettes
perfectly appropriate for this forum, no matter what vendor,
framework or individual is asking. I don't believe the opinion
just expressed represents the desires of the community.
As a member of the community, I know it doesn't represent me.
If people want to have discussion about how to integrate Spring
Security with Shibboleth in this forum, I welcome it. Anyone
who wishes to silence such discussion should reconsider the
desires of the community, where finding ways to best integrate
shibboleth with a myriad of environments we all must support
on our campuses is part of our daily work.
/mrg
Curry, Warren
With that said in every case we may not need to have the core product changed or added to. This is however a good forum for questions related to Shib and other products/technologies. OF course there may not always be an answer.
WHC
Cantor, Scott E.
> perfectly appropriate for this forum, no matter what vendor,
> framework or individual is asking.
And when the question goes unanswered because nobody on the list knows the answer?
The issue isn't whether it's "appropriate", it's whether the answer is likely to be found here. Sending somebody to the Spring list is simply doing them a favor.
Nothing precludes somebody here from answering such a question when it comes up.
> >> I think it is high time to include Spring Security SAML integration details
> >> in Shibboleth documentation.
That of course, is not up to us exclusively, it's up to people that know Spring Security. Personally, I believe such documentation belongs in Spring, but links to it, tips, or additional guidance is more than welcome in the wiki.
As the software stabilizes, I have made the point to the stakeholders that I would expect future work to shift towards investment in integration, including documentation, prototypes, tools, and so forth, for specific environments. And those kinds of investments will necessarily be much less broad in applicability, so they have to be chosen carefully as long as the resources are this tight.
-- Scott
Chad La Joie
is a question for this list. I believe it sets expectations that the
individuals who are generally counted on to answer questions can't meet.
Would it be nice if we had the expertise to answer questions for every
programming language, web server, application server, application, and
browser that plays a part in some SAML transaction, sure. But we don't
and I think leaving questions ignored and unanswered is far worse for
users than telling them where to go in order to have a higher potential
of getting an answer.
rcrathore
> Now, that said, if you happen to know of any Spring Security developers,
> and they have interest in developing a good SAML module for Spring
> Security, then let us know. As stated above we don't have the resources
> to write such a thing ourselves but, as a project, we have been doing this
> work for about 12 years. I personally would be willing to help
> implementers by at least answering some technical questions and, if time
> permits, writing and/or reviewing code. I suspect, but can't be certain,
> Scott would also be willing to answer technical questions.
>
Vladimir Schäfer has already done a great deal of work. Please see Spring
Security Extensions for SAML 2.0 at
http://static.springsource.org/spring-security/site/extensions.html Spring
Security Extensions . It was a big hit among developers in a recent Spring
conference. I would think that Vladimir will be your first point of contact
if you are interested.
Based on my observations in several forums and blogs, I am very sure that
there are several implementations out there using Spring Security Extensions
for SAML 2.0 based Service Provider talking to Shibboleth 2.0 IDP.
Regarding original question asked, I think similar to what you can see here:
https://shibboleth.usc.edu/docs/google-apps/ Achieving Single Sign-on with
Google Apps and Shibboleth 2.0 , a Spring based application can collect
information about URLs of logout, change password etc. at the time of
setting up IDP and use them to implement logout functionality if an IDP
(such as Shibboleth 2.0) does not provide any mechanism.
I acknowledge that my last post didn't come out very well and I could have
written it in a different way. The point I wanted to make is that a open
source community such as Spring or Shibboleth will continue to improve if
they also pay attention to what is happening around in technology and usage
spaces.
I also acknowledge that Spring contributors base is huge and it is
imperative that they keep an ear to the ground and be ahead in the game.
This, of course, doesn't apply to Shibboleth, which is a different kind of
community.
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5905658.html
Cantor, Scott E.
> https://shibboleth.usc.edu/docs/google-apps/ Achieving Single Sign-on with
> Google Apps and Shibboleth 2.0 , a Spring based application can collect
> information about URLs of logout, change password etc. at the time of
> setting up IDP and use them to implement logout functionality if an IDP
> (such as Shibboleth 2.0) does not provide any mechanism.
Note that Google is not something we point to as an example of good SAML integration. I'm not sure that's relevant to your point, but as I say, I'm not sure.
-- Scott
Chad La Joie
On 1/9/11 8:16 PM, rcrathore wrote:
> Vladimir Schäfer has already done a great deal of work. Please see Spring
> Security Extensions for SAML 2.0 at
> http://static.springsource.org/spring-security/site/extensions.html Spring
> Security Extensions . It was a big hit among developers in a recent Spring
> conference. I would think that Vladimir will be your first point of contact
> if you are interested.
I saw that he posted something on the Spring website a while ago but I
hadn't seen any other work on it since then so I thought the project was
dead (most SAML implementations are, as far as I can tell). The Spring
website has said it was coming soon for over a year now. And I mean no
disrespect to Vladimir, nor I have even evaluated his module but I can
tell you that getting an SP right (having it do the proper security
checks, properly interpreting various SAML message bits, etc.) is *hard*
and takes a lot of work. It's why, on the OpenSAML list, we try to
encourage people to use an existing implementation. Chances are, even if
it's not great it's better than what they'll throw together.
> Based on my observations in several forums and blogs, I am very sure that
> there are several implementations out there using Spring Security Extensions
> for SAML 2.0 based Service Provider talking to Shibboleth 2.0 IDP.
In theory it should work just fine for the most part. SAML 2 is pretty
interoperable (SAML 1 wasn't). SLO, if you check the archives, is a
feature we continue to struggle with. A vocal minority of the community
here claims to want it but does not seem to understand the significant
limitations it has in reality.
> Regarding original question asked, I think similar to what you can see here:
> https://shibboleth.usc.edu/docs/google-apps/ Achieving Single Sign-on with
> Google Apps and Shibboleth 2.0 , a Spring based application can collect
> information about URLs of logout, change password etc. at the time of
> setting up IDP and use them to implement logout functionality if an IDP
> (such as Shibboleth 2.0) does not provide any mechanism.
Yeah, that's not our document. It was written by one of our past
developers who, coincidentally, works for Google now. We are actually
in the process of revisiting how we document some items. I'm still of
two minds whether it's good to create documents like the one you
referenced. I understand that one-stop-shop documents are nice for
people but they tend to fall out of date as the rest of the
documentation changes and they don't do a very good job at illustrating
options that, in some deployments, might be necessary. I don't know
what the proper balance is.
> I acknowledge that my last post didn't come out very well and I could have
> written it in a different way. The point I wanted to make is that a open
> source community such as Spring or Shibboleth will continue to improve if
> they also pay attention to what is happening around in technology and usage
> spaces.
Yeah, I actually keep a close eye on Spring (core) since we use it in
the IdP and will be using it in other products. But frankly I see no
more people using Spring Security than I do Apache Shiro, JBoss SSO or
various other frameworks. Yes some people use them but as far as I can
tell none actually have wide adoption and so targeting any of them only
addresses a small percentage of all the apps out there.
rcrathore
Hi Scott,
I am sorry about the confusion. I think it was not clear in my post that I
was suggesting that it to the person who asked about how to implement Logout
functionality in his Spring Security based (SP) application.
Google App is just an example of a SP that is talking to Shibboleth IDP. I
think that the first screenshot in that web page (under section 'Configuring
Google Apps') could very well be implemented in a Spring Security based SP
system.
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5905709.html
Cantor, Scott E.
> was suggesting that it to the person who asked about how to implement
> Logout functionality in his Spring Security based (SP) application.
Ah, ok. Yes, I didn't pick up on that.
> Google App is just an example of a SP that is talking to Shibboleth IDP. I
> think that the first screenshot in that web page (under section 'Configuring
> Google Apps') could very well be implemented in a Spring Security based SP
> system.
Well, yes, it could, but we don't think that's an effective model. It's a one-off. Metadata is the defined mechanism in the standard to do that kind of thing.
-- Scott
rcrathore
> I saw that he posted something on the Spring website a while ago but I
> hadn't seen any other work on it since then so I thought the project was
> dead (most SAML implementations are, as far as I can tell). The Spring
> website has said it was coming soon for over a year now. And I mean no
> disrespect to Vladimir, nor I have even evaluated his module but I can
> tell you that getting an SP right (having it do the proper security
> checks, properly interpreting various SAML message bits, etc.) is *hard*
> and takes a lot of work. It's why, on the OpenSAML list, we try to
> encourage people to use an existing implementation. Chances are, even if
> it's not great it's better than what they'll throw together.
>
I am very surprised to read above comments along with your assertion that
you are a Spring user. Even an ordinary Spring developer understands that
Spring provides just a platform to integrate other frameworks, tools and
technologies and strives to remove boiler plate code and configuration to
help developers focus on business domain issues. Spring has never tried to
invent a wheel. In fact, some of Spring's way of doing things are finding
their way into mainstream Java and .NET. I don't understand what gave you
idea that Spring Security extension project is about creating new
implementation. Did Spring ever provide implementation of any technology?
Spring Security Extensions for SAML 2.0 is, in fact, based on OpenSAML 2 and
it is compiled with jar files available at
http://shibboleth.internet2.edu/downloads/maven2/. I am ready to believe
that most of the code would be in line with what your team wrote in opensaml
2 user and developers manuals. I am also sure that it would not have great
features of Shibboleth but again I believe that the best is the enemy of
good.
Developers/designers are dealing with hard situations everyday and they
implement their solutions in the way that makes most sense to them. If we
want large number of systems to get integrated with Shibboleth
IDP/Federation then why not collaborate with other communities and test
Shibboleth IDP with other SP implementations especially when SAML 2.0
encourages interoperability? (The online documentation on 'creating per
service provider' configurations seems incomplete to me.)
Take a simplified case: If a customer (a national news producer), who
already has a Spring based web application to provide content to
universities, wants to add another authentication mechanism based on IDP,
would it be a sensible decision to go for a new Shibboleth SP installation
or go for an extension of Spring security in the same setup (especially when
all SAML features are not needed)?
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5906042.html
Chad La Joie
On 1/10/11 1:39 AM, rcrathore wrote:
> Spring Security Extensions for SAML 2.0 is, in fact, based on OpenSAML 2 and
> it is compiled with jar files available at
> http://shibboleth.internet2.edu/downloads/maven2/. I am ready to believe
> that most of the code would be in line with what your team wrote in opensaml
> 2 user and developers manuals. I am also sure that it would not have great
> features of Shibboleth but again I believe that the best is the enemy of
> good.
OpenSAML isn't an SP implementation though. One way to think about it
would be by analogy. OpenSAML is to an SP (or IDP) implementation what
an HTTP library is to a web server (or browser). And the problem here
is not a case of "the best is the enemy of the good" but rather a
question of "is it secure?".
If it's lacking in features or hard to use or whatever then people won't
use it. That's fine. Either the software gets those features or not and
life goes on. But the security of the software is something most people
simply assume and few deployers can actually evaluate. So having that
part messed up is dangerous.
As I said, I don't know anything about Vladimir's code. But I do know
that nearly every SAML implementation we have tested against, including
our own at times, leaves out or messes up some aspect of the security.
Closed and Open source projects alike. So, at this point, I've learned
to be skeptical of new implementations until proven otherwise.
> Developers/designers are dealing with hard situations everyday and they
> implement their solutions in the way that makes most sense to them. If we
> want large number of systems to get integrated with Shibboleth
> IDP/Federation then why not collaborate with other communities and test
> Shibboleth IDP with other SP implementations especially when SAML 2.0
> encourages interoperability? (The online documentation on 'creating per
> service provider' configurations seems incomplete to me.)
What do you feel is incomplete? If you can describe it we can try and
address it.
> Take a simplified case: If a customer (a national news producer), who
> already has a Spring based web application to provide content to
> universities, wants to add another authentication mechanism based on IDP,
> would it be a sensible decision to go for a new Shibboleth SP installation
> or go for an extension of Spring security in the same setup (especially when
> all SAML features are not needed)?
Honestly, it depends. There are a lot of factors the go in to a
decision like that. But there have certainly been cases where I've
recommended products other than Shibboleth.
Cantor, Scott E.
> it is compiled with jar files available at
> http://shibboleth.internet2.edu/downloads/maven2/.
I think Chad's analogy is kind. I'd say it's closer to a socket library than an HTTP client or server.
> I am ready to believe
> that most of the code would be in line with what your team wrote in
> opensaml 2 user and developers manuals.
I think Chad would be the first to admit that trying to implement an SP based on the documentation we have requires that you understand how to implement one in the first place.
> Developers/designers are dealing with hard situations everyday and they
> implement their solutions in the way that makes most sense to them. If we
> want large number of systems to get integrated with Shibboleth
> IDP/Federation then why not collaborate with other communities and test
> Shibboleth IDP with other SP implementations especially when SAML 2.0
> encourages interoperability?
What do you think we need to test? It sounds like you're saying we should be the debuging and QA team for others' projects. I don't think that's particularly fair.
I also think we have a pretty decent testbed that's already available if those implementations wanted to play around with interoperability.
> Take a simplified case: If a customer (a national news producer), who
> already has a Spring based web application to provide content to
> universities, wants to add another authentication mechanism based on IDP,
> would it be a sensible decision to go for a new Shibboleth SP installation
> or go for an extension of Spring security in the same setup (especially when
> all SAML features are not needed)?
I don't think you'd agree with my answer, but which SAML features do you think aren't needed?
-- Scott
Chad La Joie
On 1/10/11 10:03 AM, Cantor, Scott E. wrote:
>> I am ready to believe
>> that most of the code would be in line with what your team wrote in
>> opensaml 2 user and developers manuals.
>
> I think Chad would be the first to admit that trying to implement an SP based on the documentation we have requires that you understand how to implement one in the first place.
Absolutely. I once told Scott, when I was starting out many years ago,
that I thought it should be pretty easy to write an SP in Java. I think
I said it shouldn't take more than a couple months. He was nice enough
not to laugh in my face.
Chad La Joie
community Scott and I did agree to post a note to their forums offering
to work with them to clarify interoperability, talk about the protocol,
why did certain things with our SP, or things along those lines. So
we'll see how it proceeds.
On 1/9/11 1:42 PM, Chad La Joie wrote:
> Now, that said, if you happen to know of any Spring Security developers,
> and they have interest in developing a good SAML module for Spring
> Security, then let us know. As stated above we don't have the resources
> to write such a thing ourselves but, as a project, we have been doing
> this work for about 12 years. I personally would be willing to help
> implementers by at least answering some technical questions and, if time
> permits, writing and/or reviewing code. I suspect, but can't be certain,
> Scott would also be willing to answer technical questions.
--
V. Schaefer
First of all thank you for your offer; I'm looking forward to working with
you.
For your information the Spring Security SAML Extension is heading towards
the first GA release, we've done a lot of work during the last six months,
our current SAML 2.0 support is on the level of SP Lite conformance
according to the OASIS requirements - with the exception of ECP SSO which is
in progress. Still quite a bit of work to do though.
To answer one of the original questions – despite it being in an incorrect
forum:
> This page about Single logout for Idp. I am looking for implementing
logout on SP side.
The Spring SAML module supports both Service Provider and Identity Provider
initialized SAML 2.0 Single Logout Profile (without SOAP binding for the
time being) which enables you to terminate the IDP session as well as all
the ones at the participating Service Providers (or proxied IDPs).
Prerequisite for usage of the profile is of course support at the IDP. Link
to the list of problems related to the profile was already posted earlier.
The module also enables you to perform a "local logout" which only
terminates the Service Provider's session - this means, just like you
noticed, that clicking the login link will create a new one. At least until
the IDP session expires.
I'm not aware of any standard way to terminate the IDP session without SLo.
- Vladimír
--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Info-Shibboleth-IdP-tp3654552p5911598.html
Cantor, Scott E.
> the first GA release, we've done a lot of work during the last six months,
> our current SAML 2.0 support is on the level of SP Lite conformance
> according to the OASIS requirements - with the exception of ECP SSO which
> is in progress. Still quite a bit of work to do though.
http://kantarainitiative.org/confluence/display/eGov/eGovernment+Implementation+Profile+of+SAML+V2.0
That goes significantly beyond anything in the original conformance set, and itself lacks a number of extensions that have been done, or are in progress, since, such as:
http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport
http://wiki.oasis-open.org/security/SAML2MetadataUI
http://wiki.oasis-open.org/security/SAML2ChannelBindingExt
http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile
> I'm not aware of any standard way to terminate the IDP session without SLo.
-- Scott