OIOSaml to Ignore IDP certificate expiry date
rpnz
I am using the OIOSaml java library to incorporate SSO into my our web
app. Is it possible to get the library
to ignore the expiry date of the IDP's certificate?
Sample log
[2010-11-12 16:08:43,656] [DEBUG] [P1-8]
[dk.itst.oiosaml.sp.metadata.IdpMetadata] Local Metadata certificate
for xxx.xxx.xxx expired at Thu Feb 26 19:10:17 NZDT 2009, current: Fri
Nov 12 16:08:43 NZDT 2010
Exception thrown
dk.itst.oiosaml.sp.model.validation.ValidationException: The assertion
is not signed correctly
at
dk.itst.oiosaml.sp.model.OIOResponse.validateResponse(OIOResponse.java:
118)
at
dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handleSAMLResponse(SAMLAssertionConsumerHandler.java:
131)
at
dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handlePost(SAMLAssertionConsumerHandler.java:
92)
at
dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:
160)
Thanks
Raj
Olav Morken
> Hi,
> I am using the OIOSaml java library to incorporate SSO into my our web
> app. Is it possible to get the library
> to ignore the expiry date of the IDP's certificate?
I don't think this list is the proper list to ask OIOSaml-questions,
since we work on a different software project (simpleSAMLphp). Maybe
you would get more responses asking on a list related to OIOSaml?
Regards,
Olav Morken
UNINETT / Feide
Peter Schober
> I am using the OIOSaml java library to incorporate SSO into my our
> web app. Is it possible to get the library to ignore the expiry date
> of the IDP's certificate?
Also note that per the Interoperable SAML 2.0 Web Browser SSO
Deployment Profile[1] "metadata MUST conform to the SAML V2.0 Metadata
Interoperability Profile Version 1.0" [2], and which states that "it
is RECOMMENDED that certificates be unexpired".
So it might be a good idea to replace those anyway.
cheers,
-peter
[1] http://saml2int.org/profile/current#section5
[2] http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf
Teddy Aprilianto
Hi Guys ,
I'm trying to set simplesamlphp as SP , but I've got error below
"This endpoint is not enabled. Check the enable options in your configuration of simpleSAMLphp"
Any advices ?
Thanks
Teddy
|
Olav Morken
> Hi Guys ,
>
> I'm trying to set simplesamlphp as SP , but I've got error below
>
> "This endpoint is not enabled. Check the enable options in your configuration of simpleSAMLphp"
It looks like you are attempting to use the old SP code. In new SP
installations you should probably use the new SP code. If you haven't
already done it, I suggest looking at the documentation:
http://simplesamlphp.org/docs/1.6/simplesamlphp-sp
(Also, please don't just hit "Reply" on an existing message when you
aren't actually replying to that message. When you do that, your
message appears as a reply to that message in various email clients.)
Teddy Aprilianto
| Oh sorry for that , thanks for remind me . Yes , I'm using v 1.4 . I'm still using this for Idp between one server and googleapps , working well until now . And now I'm trying to set SP in other server . Is this version still workable ? Another question , for example I put simplesamlphp as IDp in folder A (existing application) and as SP in folder B (new installation) . Can this make a problem with current one and or new one ? Thanks Teddy --- On Mon, 11/15/10, Olav Morken <olav....@uninett.no> wrote: |
Olav Morken
> Oh sorry for that , thanks for remind me .
>
>
>
> Yes , I'm using v 1.4 . I'm still using this for Idp between one server and googleapps , working well until now .
>
>
>
> And now I'm trying to set SP in other server . Is this version still workable ?
It shouldn't suddenly break, but there have been many fixes for various
things since version 1.4.
You haven't accidentaly overwritten a configuration file or something
like that? What URL do you receive the error message on?
> Another question , for example I put simplesamlphp as IDp in folder A (existing
> application) and as SP in folder B (new installation) . Can this make a
> problem with current one and or new one ?
Yes, unless you configure them with different session cookies. If they
share a single session cookie, they will share a single session object,
and session objects aren't compatible between different versions.
(Session objects can usually be upgraded from one version to the next,
but not the other way around, and not with more than one version
difference.)
Tom Scavo
<sp+lists....@univie.ac.at> wrote:
> * rpnz <raj...@gmail.com> [2010-11-15 05:59]:
>> I am using the OIOSaml java library to incorporate SSO into my our
>> web app. Is it possible to get the library to ignore the expiry date
>> of the IDP's certificate?
>
> Also note that per the Interoperable SAML 2.0 Web Browser SSO
> Deployment Profile[1] "metadata MUST conform to the SAML V2.0 Metadata
> Interoperability Profile Version 1.0" [2], and which states that "it
> is RECOMMENDED that certificates be unexpired".
> So it might be a good idea to replace those anyway.
While all of that is good advice, it may be instructive to read that
sentence in context:
"In the case of an X.509 certificate, there are no requirements as to
the content of the certificate apart from the requirement that it
contain the appropriate public key. Specifically, the certificate may
be expired, not yet valid, carry critical or non-critical extensions
or usage flags, and contain any subject or issuer. The use of the
certificate structure is merely a matter of notational convenience to
communicate a key and has no semantics in this profile apart from
that. However, it is RECOMMENDED that certificates be unexpired."
In the InCommon Federation, for example, we certainly call out the IOP
requirements with respect to expired certificates ("a certificate in
metadata that expires SHOULD be removed") but at the same time, it is
up to Federation participants how and when this will be done, so there
*are* expired certificates in Federation metadata and there is little
that can be done about it.
In the end, an implementation that gracefully handles expired
certificates in metadata is preferred to one that does not. Indeed, an
implementation in the latter category is not recommended to Federation
participants.
> [1] http://saml2int.org/profile/current#section5
> [2] http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf
Note that the latter profile is under development again:
http://wiki.oasis-open.org/security/SAML2MetadataIOP
Cheers,
Tom
Peter Schober
> In the end, an implementation that gracefully handles expired
> certificates in metadata is preferred to one that does not. Indeed,
> an implementation in the latter category is not recommended to
> Federation participants.
I guess this boils down to Postel's Law a.k.a. the
http://en.wikipedia.org/wiki/Robustness_principle
with "conservative sending" meaning: include non-expired certs for
your own entities, to not trip up lesser SAML implementations.
Likewise "liberal acceptance" translates to not refusing service based
on failing X.509 validation (which the OP has as MUST NOT, IIRC),
-peter
Teddy Aprilianto
| Hi, Thanks much for your explanations . I have situation like this . Server 1 : Idp ( v 1.4 ) Server 2 : Google (sp) have been working well since 2 years ago . Now new story comes : Server X comes and act as maingate and IDP . But we still keep server 1, so in other part , server 1 also act as SP . IDP in server X developed by other party and not using simplesamlphp . Then I created an SP in server 1 (using simplesamlphp and located in different folder ). I've set the configuration in new SP (seems I read configuration steps for v 1.6 :-) , should read v 1.4 ) . SSO between server 1 and google is still working fine
( I did nothing with the configurations) , but server 1 and server X still not work with that messages ( This endpoint is not enabled ) What do you think ? I'll try to implement v 1.6 for SP . Really appreciate for any assistances Thanks Teddy |
|
Olav Morken
> Hi,
> Thanks much for your explanations .
> I have situation like this .
> Server 1 : Idp ( v 1.4 )
> Server 2 : Google (sp)
> have been working well since 2 years ago .
> Now new story comes :
> Server X comes and act as maingate and IDP . But we still keep server 1, so in other part , server 1 also act as SP .
> IDP in server X developed by other party and not using simplesamlphp . Then I created an SP in server 1 (using simplesamlphp and located in different folder ). I've set the configuration in new SP (seems I read configuration steps for v 1.6 :-) , should read v 1.4 ) .
> SSO between server 1 and google is still working fine ( I did nothing with the configurations) , but server 1 and server X still not work with that messages ( This endpoint is not enabled )
You still haven't said what page you receive that error on.
> What do you think ? I'll try to implement v 1.6 for SP .
I suggest that you start with a new installation of simpleSAMLphp, and
try to follow the installation guide. Remember to change the
'baseurlpath' option in config.php to reflect the URL that the new
installation is available on.